Работа с Git

Правила оформления веток

Все проекты имеют кодовое имя, часто в виде аббревиатуры. Для примера будем использовать PRJ. Кодовое имя проекта используется в качестве префикса повсеместно. Те же задачи могут быть доступны по префиксу и номеру, например, PRJ-123.

Названия веток формируются по git flow. Ветки, предназначенные для слияния в develop, начинаются с feature/.

Затем идёт код документа в JIRA, например, PRJ-123.

Следом лаконичное описание цели правок, например, _show_report_modal.

Примеры:
feature/PRJ-123_show_report_modal
feature/PRJ-124_check_type

Правила оформления коммитов и комментариев к ним

В коммитах важна атомарность, а в комментариях — цель.

Коммиты бывают «по делу» и «во благо».

По делу

То есть в соответствии с целью документа в JIRA. Комментарий коммита «по делу» формируется по схеме

<код документа в JIRA>. <тип коммита> (<имя модуля>[, <имя модуля N>]): <что сделать>[.]
[<подробности, если надо>]
[<подробности, если надо>]

Например,

PRJ-123. Feature (ReportPage, ReportModal): Show report modal

Во благо

Например, рефакторинг модуля, приведение к стилю кода или исправление опечатки коллеги — то, что к цели документа в JIRA не относится (слабо относится). Комментарий коммита «во благо» формируется по схеме

<тип коммита> (<имя модуля>[, <имя модуля N>]): <что сделать>[.]
[<подробности, если надо>]
[<подробности, если надо>]
With <код документа в JIRA>

Например,

Refactor (ReportPage): Correct indents, apply code style, correct typo.
With PRJ-122

Допускается

Refactor (ReportPage): Code style, typo.
With PRJ-122

Типы коммитов

Feature — новая функциональность;
Bugfix — исправление ошибок;
Docs — изменения только в документации;
Style — работа со стилями, дизайном и т.д.;
Refactor — изменение кода, которое не исправляет ошибку и не добавляет функцию;
Test — добавление отсутствующих тестов или исправление существующих тестов;
Perf — изменение кода, повышающее производительность;
Build — изменения, влияющие на систему сборки, конфигурации или внешние зависимости (например, области: gulp, webpack, npm).

Примечания

Прежде, чем сделать коммит, проверяем, что в него попадает. Отладочные фрагменты удаляем.

Создавая коммит, думаем, что его придётся откатить (revert) или скопировать в другую ветку (cherry-pick) — обеспечиваем атомарность.

Оставляя комментарий, думаем о других людях. Автор коммита в будущем — тоже другой человек.

Первая строка комментария — своего рода заголовок. Часто так и отображается в средствах работы с репозиториями (например, в GitLab). В первой строке оставляем только важное.

В комментарии используем знаки препинания. Последняя точка избыточна.

Когда строк более одной — в первую строку-заголовок добавляем точку.

Так как коммит может быть скопирован в другую ветку (cherry-pick), распространена практика писать пояснение, отвечая на вопрос «Что сделать?», а не «Что сделал(а)?». Это так же удобно при просмотре истории.

Мы пишем комментарии на английском языке (развиваем навык, ленимся переключать раскладку), но важнее написать понятно (можно на русском) и грамотно. Следим за верным указанием кода документа в JIRA, избегаем опечаток.

Заботясь об истории правок, осваиваем stash и amend.

Конфликты должны быть редкостью. Встречаешь конфликт — смотришь, кто менял файл параллельно с тобой — собираются все, менявшие конфликтные строки, и решают конфликты.

Перед вливанием веток обе ветки необходимо обновить.

Неполадки при использовании git push --force и затирании истории исправляет автор.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!