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

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

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

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

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

Упрощение стратегии ветви

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

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

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

Использование ветвь компонента для работы

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

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

Назовите ветвь компонента по соглашению

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

Некоторые варианты именования ветвь компонента:

• users/username/description
• users/username/workitem
• исправление или описание
• feature/feature-name
• feature/feature-area/feature-name
• исправление/описание

Примечание.

Сведения о настройке политик для применения стратегии именования ветвей см. в разделе "Требовать папки ветви".

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

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

Проверка и слияние кода с помощью запросов на вытягивание

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

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

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

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

Обеспечение высокого качества актуальной основной ветви

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

Настройте политику ветвей для основной ветви, которая:

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

Совет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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