Эффективная стратегия ветвления Git, о которой должен знать каждый разработчик

Для тех, кто хочет научиться эффективно работать в команде и применять Git, в Слёрме подготовили практический курс и перевод интересного материала о стратегии ветвления.

Оригинал статьи (автор Anurag Sidana)

Подробности о курсе

Какой должна быть основная ветка: master, develop или что-то еще? Давайте взглянем на стратегию ветвления Git, с которой вы можете быть еще не знакомы.

• На какой ветке надо создавать feature ветку?
• После завершения кода в какой ветке стоит создавать MR (Merge Request)/PR (Pull Request) для проверки и тестирования кода?
• С какой веткой сливать эту feature ветку после завершения тестирования и анализа?

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

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

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

В ней используются ветви master, develop и feature.

master

• Мы называем ее продакшн веткой. В ней находится хорошо протестированный стабильный код.
• Из этой ветки должен был произойти предыдущий релиз, и следующий также должен быть из нее.
• У нас могут быть пайплайны для релиза из этой ветки (т.е. каждый раз, когда происходит очередное слияние в эту ветку, автоматически запускается пайплайн, который делает сборку и деплой ПО на наши рабочие серверы).
• Она должна принимать слияния только с веткой develop.

develop

• Ветка на нижнем по отношению к master уровне.
• Разработчик, начинающий работать над какой-то функцией, создаёт новую ветку из этой ветки.
• После завершения разработки/тестирования/анализа кода разработчик создаёт MR/PR на ту же самую ветку, так как именно из этой ветки мы будем собирать следующий релиз.
• Для того, чтобы зарелизить состояние проекта в этой ветке, мы делаем мерж в ветку master.

feature

• Ветка, создаваемая из develop для работы над запланированной на следующий выпуск функцией.
• Обычно в этой ветке работает один разработчик.

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

Однако мы пропустили одну вещь: тестирование QA.

На какой ветке его делать? Другими словами, какую ветку следует развернуть в среде QA?

Самый простой подход: иметь среду QA на ветке разработки (т. е. серверы QA будут развернуты со сборкой, выпускаемой из ветки develop). А после завершения тестирования и контроля качества создается MR/PR в ветку master.

Плюсы

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

Минусы

• Если в изменениях в одной из feature веток есть баг, то тестирование и QA будет заблокировано и создаст простой для команды.

Первое решение

Подождать, пока автор feature-ветки исправит проблему. Слить ее с веткой develop, снова развернуть ее в среде QA и возобновить тестирование. Но это нецелесообразный вариант, поскольку мы не знаем, сколько времени понадобится на исправление того или иного бага.Кроме того:

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

Второе решение

Отменить изменения этой функции и продолжить тестирование. Такой подход эффективнее с точки зрения продуктивности команды, однако для автора feature-ветки он может быть болезненным. Отмена изменений приведет к созданию нового коммита, что вызовет отмену всех изменений от этих разработчиков в данной ветке. А если они попытаются после исправления багов слить ее обратно, Git будет использовать для слияния с develop только новые коммиты исправлений, так как более старые коммиты уже находятся в истории коммитов develop.

Чтобы решить эту проблему, разработчику нужно отменить коммит отмены.

Третье решение

Третьим и самым простым решением будет принудительно запушить master в develop, заново слить остальные ветки feature и заново запустить QA.

Для продуктивности команды я бы порекомендовал второй путь.

Всю эту проблему можно решить следующим образом: создать еще одну веку QA для тестирования. В идеале QA должна обновляться вместе с develop .

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

• Начинаете новую ветку из develop.
• После разработки и тестирования создаёте PR/MR на QA для анализа кода.
• После анализа кода сливаете ее с веткой QA.
• QA проводит тестирование функции, и после теста вы создаёте MR/PR на develop.
• Проводите второй раунд анализа (для спокойствия) и сливаете вашу ветку напрямую в develop, поскольку она уже проанализирована и протестирована.
• Как только develop готова к релизу (то есть все feature ветки слиты), QA запускает сборку для проведения регрессионного тестирования. Этот билд можно запустить в уже созданной среде QA.

Преимущества этого подхода

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

• Вы можете проводить тестирование функций на ветке QA, регрессионное тестирование на стабильной ветке develop после слияния всех функций, которые запланированы в текущем выпуске.
• Ветка develop всегда будет стабильна, а любой разработчик сможет пустить от нее свою ветку feature в любое время.
• Вы не будете засорять историю коммитов в ветке develop.
• Если у QA появятся проблемы с любой веткой feature, вы сможете их решить и провести без отмены изменений, если эта функция независима от других.
• Патч (hotfix): в случае любой проблемы с продуктом начните ветку из master, исправьте проблему, и зарелизьте.