Эффективная стратегия ветвления 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 на ветке разработки (т. е. серверы 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, исправьте проблему, и зарелизьте.