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

Azure DevOps Services | Azure DevOps Server 2022 г. - Azure DevOps Server 2019 г. | TFS 2018

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

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

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

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

Упростите стратегию ветвей. Создайте стратегию на основе следующих трех понятий:

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

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

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

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

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

Именуйте ветви компонентов по соглашению

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

Некоторые рекомендации по именованию ветвей компонентов:

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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