Все проекты имеют кодовое имя, часто в виде аббревиатуры.
Для примера будем использовать 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 и затирании истории исправляет автор.