Лучшие навыки работы с Git: Руководство по соглашениям о ветках и коммитах

Вы можете знать, как работает этот инструмент, но вы также должны понимать цель его изобретения для решения реальных проблем.

Вы уже знакомы с концепциями Git и используете Git в своих проектах. Но подождите, вы используете его эффективно?

Изучив различные блоги и ветки блогов, я обнаружил замечательные приемы, которые используют опытные программисты при работе с Git. Я имею в виду различные материалы Git, предназначенные для улучшения взаимодействия и совместной работы в команде.

Разработчики всегда выполняют 90% работы, но как опытные разработчики мы часто игнорируем оставшиеся 10% работы по документированию кода. Даже если вы создали лучший продукт или функцию, если никто другой не может их понять или использовать, какова была цель их разработки? Вот где полезны понятный и структурированный документ или заметки.

Группа поддержки кода сталкивается с рядом недоразумений и проблем из-за отсутствия подходящих соглашений об именах. Давайте посмотрим, какие хорошие соглашения об именах соблюдаются опытными разработчиками.

Стандарты имен веток Git

Всегда помните, что вы не единственный, кто работает над проектом; рядом с вами или вашей заменой всегда будет кто-то, работающий над кодовой базой проекта. Следовательно, вы не можете работать только с одной главной веткой. Вам нужно работать над разными ветвями, которые имеют разные цели.

Стандарт именования ветвей Git позволяет систематически разрабатывать проект. Он служит для тщательного разделения работы.

<unique_id>-<branch_type>-<seperator>-<branch_name>

На приведенной выше диаграмме представлены компоненты, участвующие в соглашениях об именах ветвей:

уникальный_идентификатор:

Лидирование с использованием идентификатора системы отслеживания задач, номера тикета Jira или любого другого уникального_идентификатора с помощью программного обеспечения для управления проектами является простым, не требует особых размышлений и предлагает дополнительные преимущества:
В большинстве случаев проблемы, созданные в системе отслеживания проблем, используются для отслеживания прогресса команды. Подключить соответствующую рабочую ветку к каждому заданию просто, особенно когда каждый разработчик работает над многими ошибками одновременно.
Система отслеживания проблем значительно упрощает поиск и фильтрацию. Получив номер проблемы, вы можете легко найти ветку в локальном дереве git с помощью автозаполнения.

branch_type:

Добавление ключевого слова, которое классифицирует филиал, является одним из лучших способов повысить эффективность. Общая цель состоит в том, чтобы выбрать короткие слова. Выбор слова может быть любым, подходящим для вашего проекта.

Вот некоторые общие ключевые слова:

fix: ошибка, которая должна быть исправлена.
исправление: ошибка, которую необходимо исправить в первую очередь.
функция:представление новой ветки функций.
WIP: Работа продолжается и не будет завершена в ближайшее время.

разделитель:

Многие разработчики используют косые черты в качестве разделителей, а другие используют дефисы. Какой из них использовать, определяется вашим выбором и выбором вашей команды.

Дефисы, вероятно, облегчают понимание имени, поэтому они являются хорошим разделителем в названиях ветвей. Допускаются косые черты, дефисы и символы подчеркивания. Цель состоит в том, чтобы сохранить последовательность.

Преимущества разделителей:
1. Улучшает читаемость и уменьшает путаницу;
2. Упрощает работу, особенно при работе с несколькими ветвями.

название_ветви:

Следует избегать длинных описательных имен для долгоживущих ветвей.
Избегайте использования не буквенно-цифровых символов в названии ветки.
Создает имена, которые не требуют пояснений для рецензентов.

Пример:
[2023]-feature/implement-user-authentication-module

Стандарты сообщений Git Commit

Лишь немногие программисты действительно способны составить правильное сообщение коммита. Если вы хотите повысить стандарты сообщений коммитов, следуйте приведенным ниже рекомендациям.

Самый простой способ объяснить контекст изменения другим разработчикам, работающим над этим проектом, и даже самому себе — это хорошо написанное сообщение о коммите Git.

1. Тип фиксации

Некоторые хорошие типы коммитов, определенные Натали Пиной:

feat: с изменениями представлена новая функция.
fix: произошло исправление ошибки.
рутина: изменения, которые не относятся к исправлению или функции и не изменяют src или тестовые файлы (например, обновление зависимостей).
рефакторинг: переработанный код, который не исправляет ошибку и не добавляет новую функцию.
docs: обновления документации, такие как README или другие файлы уценки.
стиль: изменения, не влияющие на смысл кода, вероятно, связанные с форматированием кода, например пробелами, отсутствием точек с запятой и т. д.
тест: включение новых или исправление предыдущих тестов.
perf: повышение производительности.
ci:связана с непрерывной интеграцией.
сборка: изменения, влияющие на систему сборки или внешние зависимости.
revert: отменяет предыдущую фиксацию.

2. Область фиксации

Область действия должна включать заключенное в круглые скобки существительное, описывающее часть кодовой базы, которая будет затронута изменениями.

feat(products)
fix(payment)
style(login)

3. Тема

Предоставьте краткую однострочную сводку примененных изменений.

Ограничьте строку темы до 50 символов.
Оно не должно быть пустым и не должно содержать пробелов и знаков препинания.
Не заканчивайте строку темы точкой.
Используйте настоящее время или повелительное наклонение в теме письма. Почему? На этот вопрос лучше ответит Мэтт Квингли.

feat(products): fetchproduct with barcode
fix(payment): process multiple payments
style(login): update login form button

4. Тело

Используйте тело, чтобы описать свои модификации и почему вы их сделали.

Пустая строка должна использоваться для отделения темы от тела.
Каждая строка должна быть не длиннее 72 символов.
Не думайте, что рецензент знает исходную проблему; убедитесь, что вы включили его.
Не верьте, что ваш код говорит сам за себя.

fix(payment): process multiple payments

BREAKING CHANGE: fix bug which disabled the payment method 
to execute multiple payments at same time.

5. Нижний колонтитул (необязательно)

Раздел нижнего колонтитула используется для ссылки на проблемы, затронутые изменениями кода, или для упоминания других рецензентов кода, разработчиков или тестировщиков из команды.

fix(payment): process multiple payments

BREAKING CHANGE: fix bug which disabled the payment method 
to execute multiple payments at same time.

Reviewed-by: @John Doe
Refs #2023

Лучшие практики:

Совершайте небольшие коммиты.

Коммит должен быть оболочкой для связанных изменений для хорошего управления исходным кодом и улучшения обслуживания. Например, исправление двух разных проблем должно привести к двум отдельным коммитам.
Чем меньше размер коммитов, тем проще другим разработчикам понять изменения и отменить их, если что-то пойдет не так.

2. Часто совершайте коммиты

Ранние и частые коммиты делают ваши коммиты небольшими и позволяют фиксировать только релевантные изменения. Кроме того, это позволяет вам более регулярно делиться своим кодом с другими, избегая конфликтов слияния.

3. Перед фиксацией протестируйте свой код

Не поддавайтесь желанию совершить что-либо, что, по вашему мнению, уже завершено. Тщательно протестируйте его, чтобы убедиться, что он завершен и не имеет негативных последствий (как ранее заявлял тестер).

Заключение

Написание эффективных сообщений о коммитах — очень полезный навык, поскольку он позволяет вам взаимодействовать и работать с вашей командой. Коммиты действуют как репозиторий для изменений. У них есть потенциал стать историческим документом, позволяющим нам читать прошлое и делать осознанный выбор в будущем.

Уже есть согласованные стандарты, которым мы можем следовать, но если ваша команда согласится с описательным соглашением с учетом будущих читателей, это, безусловно, принесет долгосрочные выгоды.

В этом посте мы узнали о нескольких стратегиях улучшения наших сообщений о коммитах. Как, по вашему мнению, эти стратегии улучшат ваши коммиты? Ответьте на него в комментариях.

Спасибо за прочтение, надеюсь, вы узнали что-то новое! Если вы сочтете это полезным, отреагируйте 👏 или не стесняйтесь делиться своими взглядами и делиться ими с другими разработчиками, чтобы облегчить их жизнь.