Внедрение стратегии ветвления Git

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

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

Следующие стратегии ветвления основаны на том, как мы используем Git здесь в Корпорации Майкрософт. Дополнительные сведения см. в статье "Использование Git в Майкрософт".

Держите стратегию ветвей простой

Оставьте стратегию ветви простой. Создайте стратегию из следующих трех концепций:

• Используйте ветви возможностей для всех новых возможностей и исправления ошибок.
• Объединяйте проектные ветки в основную ветку с помощью пулл-запросов.
• Поддерживайте высокое качество и актуальность основной ветки.

Стратегия, которая расширяет эти понятия и избегает противоречий, приведет к рабочему процессу управления версиями для вашей команды, которая является согласованной и легкой.

Использование фичевых веток для вашей работы

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

Создание ветвей функций для всех изменений упрощает просмотр журнала. Посмотрите на коммиты, сделанные в ветви, и на pull request, который объединил эту ветвь.

Назовите ваши функциональные ветки согласно соглашению

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

Некоторые варианты именования ветвей функций:

• пользователи/имя_пользователя/описание
• пользователи/имя пользователя/элемент работы
• исправление или описание
• функция/feature-name
• feature/feature-area/feature-name
• оперативное исправление/описание

Используйте флаги функций для управления длительными ветками

Дополнительные сведения об использовании флагов функций в коде.

Проверка и слияние кода с помощью pull request.

Проверка кода в пулл-реквесте имеет решающее значение для улучшения его качества. Только слияние ветвей через запросы на вытягивание, которые проходят процесс проверки. Избегайте объединения ветвей в основную ветвь без pull request.

Проверка запросов на вытягивание занимает время. Ваша команда должна договориться о том, чего ожидают от авторов pull request и рецензентов. Распределите обязанности рецензента для обмена идеями по всей команде и распространения знаний о базе кода.

Некоторые предложения для успешных пул-реквестов:

• Два рецензента — оптимальное число на основе исследований.
• Если у вашей команды уже есть процесс проверки кода, внесите запросы на вытягивание в то, что вы уже делаете.
• Обратите внимание при назначении тех же рецензентов для большого количества пулл-реквестов. Запросы на вытягивание лучше работают, когда обязанности рецензента разделяются в рамках команды.
• Предоставьте достаточно подробных сведений в описании, чтобы быстро привлечь рецензентов к работе с изменениями.
• Включите сборку или связанную версию изменений, работающих в тестовой среде, с вашим pull-запросом. Другие могут легко протестировать изменения.

Поддерживайте высокое качество, up-to-date основной ветви

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

Настройте политику для основной ветки таким образом, чтобы:

• Требуется пул-реквест для слияния кода. Этот подход предотвращает прямые отправки в основную ветвь и обеспечивает обсуждение предлагаемых изменений.
• Автоматически добавляет рецензентов при создании запроса на вытягивание. Добавленные члены команды просматривают код и комментируют изменения в пул-реквесте.
• Требует успешной сборки для выполнения запроса на вытягивание. Код, объединенный в основную ветвь, должен выполняться чисто.

Управление выпусками

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

Использование ветвей выпуска

Создайте ветку релиза из основной ветки при приближении к выпуску или другой вехе, например конца спринта. Присвойте этой ветви четкое имя, связав его с выпуском, например release/20.

Создайте ветки, чтобы исправить ошибки из релизной ветки и объединить их обратно в релизную ветку через pull request.

Перенос изменений обратно в основную ветвь

Убедитесь, что исправления приземляются как в ветви выпуска, так и в главной ветви. Одним из способов является внесение исправлений в ветвь выпуска, а затем внесение изменений в основную ветвь, чтобы предотвратить регрессию в коде. Другой подход (и тот, который используется командой Azure DevOps) заключается в том, чтобы всегда вносить изменения в основной строке, а затем переносить их в ветвь выпуска. См. дополнительные сведения о стратегии потока выпуска .

В этом разделе мы рассмотрим внесение изменений в ветвь выпуска и перенос их в основную строку. Используйте чери-пик вместо объединения, чтобы точно контролировать, какие коммиты переносятся обратно в основную ветку. Объединение релизной ветки в основную ветвь может привести к релизным изменениям, которые не нужны в основной ветви.

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

1. Создайте новую ветвь компонента от основной ветви, чтобы перенести изменения.
2. Выберите изменения из ветви выпуска в новую ветвь функций.
3. Объедините функциональную ветвь обратно в основную ветвь во втором pull request.

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

Почему бы не использовать теги для выпусков?

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

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

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

Управление развертываниями

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

Исключение из этой рекомендации заключается в том, что вы используете форму непрерывного развертывания. Используйте Azure Pipelines при работе с непрерывным развертыванием для продвижения сборки из основной ветви в целевые среды развертывания.