- Сообщения
- 1.025
- Реакции
- 1.533
Git – самая популярная система контроля версий: большинство разработчиков используют ее и для личных, и для командных проектов. При этом многие разработчики, особенно начинающие, небрежно подходят к выбору названий ветвей и оформлению коммитов. Это оставляет не лучшее впечатление об их профессионализме, но что еще хуже – затрудняет командную работу и усложняет поддержание кодовой базы. В этой статье мы разберем лучшие практики для работы с ветвями и коммитами.
Названия ветвей: рекомендации сообщества
Одна из самых важных практик при работе в системе версий – использование понятных и описательных имен для веток, коммитов, запросов на вытягивание и так далее. Описательныe названия:
1.Помогают отслеживать историю изменений кода.
2.Упрощают документирование процесса.
3.Повышают эффективность работы.
Соблюдение соглашений, созданных сообществом, носит рекомендательный характер – никто не принуждает разработчиков соблюдать эти правила. Однако если вы попробуете следовать этим рекомендациям, то быстро заметите, что они действительно упрощают и ускоряют работу.
Итак, оптимальное название ветви соответствует этим критериям:
1.Дает четкое и ясное представление о том, что именно делает содержащийся в ветви код.
2.Написано в нижнем регистре. Верхний регистр и тем более капслок, как правило, не используют. Есть только одно исключение – когда в префиксе необходимо использовать номера задач из таск-менеджеров (об этом ниже).
3.Состоит только из букв и цифр (a-z, 0-9), не содержит специальных символов.
4.При необходимости разделено дефисами -. Если название состоит из нескольких слов, имеет смысл разделить их дефисами. Не следует использовать PascalCase, camelCase или snake_case.
5.Не заканчивается дефисом. Поскольку дефис используется для разделения слов, нет смысла использовать его в конце названия.
6. Не содержит повторяющихся дефисов --. Если нужно начать название с типа ветки (feature, bugfix, hotfix), используйте слэш / для отделения типа от основного названия.
Примеры корректных названий:
1.Помогают отслеживать историю изменений кода.
2.Упрощают документирование процесса.
3.Повышают эффективность работы.
Соблюдение соглашений, созданных сообществом, носит рекомендательный характер – никто не принуждает разработчиков соблюдать эти правила. Однако если вы попробуете следовать этим рекомендациям, то быстро заметите, что они действительно упрощают и ускоряют работу.
Итак, оптимальное название ветви соответствует этим критериям:
1.Дает четкое и ясное представление о том, что именно делает содержащийся в ветви код.
2.Написано в нижнем регистре. Верхний регистр и тем более капслок, как правило, не используют. Есть только одно исключение – когда в префиксе необходимо использовать номера задач из таск-менеджеров (об этом ниже).
3.Состоит только из букв и цифр (a-z, 0-9), не содержит специальных символов.
4.При необходимости разделено дефисами -. Если название состоит из нескольких слов, имеет смысл разделить их дефисами. Не следует использовать PascalCase, camelCase или snake_case.
5.Не заканчивается дефисом. Поскольку дефис используется для разделения слов, нет смысла использовать его в конце названия.
6. Не содержит повторяющихся дефисов --. Если нужно начать название с типа ветки (feature, bugfix, hotfix), используйте слэш / для отделения типа от основного названия.
Примеры корректных названий:
Код:
feature/new-sidebar
add-new-sidebar
hotfix/interval-query-param-on-get-historical-data
Неправильные названия:
fixSidebar
feature-new-sidebar-
FeatureNewSidebar
feat_add_sidebarРекомендации по префиксам
Иногда назначение ветви сложно определить по одному лишь названию. Чтобы явно указать назначение ветви (исправление бага, новая функциональность, обновление документации и т.п.), принято использовать префиксы.
Вот общепринятые префиксы:
1. feature – указывает на то, что в ветке разрабатывается новая фича, например feature/add-filters говорит о том, что в этой ветке идет работа по добавлению фильтров.
2. release – используется для подготовки новых версий. Например, в ветке release/v3.3.1-beta делают последние правки и проверки перед выпуском новой версии: исправляют оставшиеся баги, обновляют документацию, меняют номер версии в коде и т.д. После того как подготовка завершена, содержимое ветки release сливают (merge) обратно в основную ветку. В результате в репозитории появляется новая версия кода со всеми изменениями из ветки release. Ее и выпускают как новый релиз.
3. bugfix – применяется для исправления ошибок в коде. Обычно такая ветка создается при наличии конкретной проблемы (issue) с описанием найденного бага. Например, bugfix/sign-in-flow означает исправление ошибки в процессе входа в систему авторизации.
4. hotfix – похож на bugfix, с одним важным отличием: hotfix используется для быстрого исправления критических багов, которые уже попали в продакшен. Например, hotfix/cors-error означает исправление срочной ошибки CORS, связанной с междоменными запросами, которая сломала работу приложения в продакшене.
5. docs – обозначает ветку, предназначенную для написания документации к проекту. Например, docs/quick-start – это ветка для написания инструкции по быстрому запуску проекта.
Вот общепринятые префиксы:
1. feature – указывает на то, что в ветке разрабатывается новая фича, например feature/add-filters говорит о том, что в этой ветке идет работа по добавлению фильтров.
2. release – используется для подготовки новых версий. Например, в ветке release/v3.3.1-beta делают последние правки и проверки перед выпуском новой версии: исправляют оставшиеся баги, обновляют документацию, меняют номер версии в коде и т.д. После того как подготовка завершена, содержимое ветки release сливают (merge) обратно в основную ветку. В результате в репозитории появляется новая версия кода со всеми изменениями из ветки release. Ее и выпускают как новый релиз.
3. bugfix – применяется для исправления ошибок в коде. Обычно такая ветка создается при наличии конкретной проблемы (issue) с описанием найденного бага. Например, bugfix/sign-in-flow означает исправление ошибки в процессе входа в систему авторизации.
4. hotfix – похож на bugfix, с одним важным отличием: hotfix используется для быстрого исправления критических багов, которые уже попали в продакшен. Например, hotfix/cors-error означает исправление срочной ошибки CORS, связанной с междоменными запросами, которая сломала работу приложения в продакшене.
5. docs – обозначает ветку, предназначенную для написания документации к проекту. Например, docs/quick-start – это ветка для написания инструкции по быстрому запуску проекта.
Использование номеров задач в префиксах
Многие команды используют системы трекинга задач – Jira, Trello, ClickUp и т.д. В этих таск-менеджерах каждая задача получает уникальный номер, например T-142. Чтобы увязать работу в Git с этими задачами, в имени ветки указывают ее номер в неизменном виде. Например:
feature/T-531-add-sidebar – ветка для новой фичи, описанной в задаче T-531
docs/T-789-update-readme – обновление документации по задаче T-789
hotfix/T-142-security-path – исправление уязвимости в продакшене из задачи T-142
Такой подход позволяет синхронизировать работу в Git с общим планированием и отслеживанием прогресса всей команды в системе задач: менеджер сразу видит, какая ветка соответствует какой задаче из общего плана.
feature/T-531-add-sidebar – ветка для новой фичи, описанной в задаче T-531
docs/T-789-update-readme – обновление документации по задаче T-789
hotfix/T-142-security-path – исправление уязвимости в продакшене из задачи T-142
Такой подход позволяет синхронизировать работу в Git с общим планированием и отслеживанием прогресса всей команды в системе задач: менеджер сразу видит, какая ветка соответствует какой задаче из общего плана.
