GitFlow, GithubFlow, Trunk based development. Выбираем оптимальную модель ветвления

Принятие решений при разработке редко бывает столь значимым, как выбор методологии ветвления. Известный факт: с момента создания Git в 2005 году Линусом Торвальдсом для управления разработкой ядра Linux, этот инструмент прошёл долгий путь от простого механизма версионного контроля до основы современных практик DevOps. Именно ветвление Git позволило разработчикам по всему миру организовать параллельную работу над масштабными проектами, обеспечивая при этом исключительную гибкость и контроль над каждой линией кода.

Выбор стратегии ветвления не только влияет на сроки релизов, но определяет, как команда будет реагировать на ошибки продакшн-контура, внедрять новые фичи и управлять несколькими версиями продукта одновременно. Сейчас обсуждение GitFlow, GitHub Flow, Trunk Based Development становится не просто техническим рассмотрением, а стратегическим выбором, который может определить будущее проекта.

cloud

Git Flow

Git Flow — это модель ветвления, предложенная Винсентом Дрийсеном в 2010 году. Модель ориентирована на проекты с релизными циклами, поддерживает множество версий репозитория.

Работа с данной моделью начинается с создания ветки develop от ветки master.

git init
git checkout -b develop

В ветке develop будет храниться код, актуальный для текущего релиза. Напрямую сделать коммит в main или develop нельзя, все обновления будут заноситься через слияние. Для каждой фичи/задачи разработчик будет создавать новую ветку с префиксом feature от develop.

git checkout develop
git checkout -b feature/email_verification

После того как был разработан и протестирован функционал ветки feature/email_verification, она сливается с develop.

git checkout develop
git merge --no-ff feature/email_verification

При слиянии флаг --no-ff позволяет сохранить историю коммитов c учетом веток, даже если при слиянии история ветки develop не менялась.

Так сейчас выглядит история веток: разработка на ветках feature/email_verification и feature/sms_verification была закончена, а ветки слиты в develop. Ветка feature/guest_no_verification все еще в работе и не войдет в текущий релиз.

Согласно модели GitFlow фичи из текущего релиза должны быть отправлены в релизную ветку — это ветки с префиксом release, из ветки develop.

git checkout develop
git checkout -b release/1.0.0

Релизные ветки release необходимы для закрепления фич релиза, дополнять данную ветку новыми фичами — нельзя. Можно исправлять ошибки или документировать код, править конфиги. После того, как ветка release/1.0.0 готова и протестирована, ее можно сливать с main, которая всегда хранить только актуальный код прода.

git checkout master
git merge --no-ff release/1.0.0

Пока коллеги готовили релиз, разработчик завершил работу над feature/guest_no_verification, затем слил ее с develop. Прямо сейчас, ветка develop не содержит новых изменений релизной ветки и master соответственно. В модели GitFlow это частая ситуация, поскольку ветки фич могу жить довольно долго и переходить из релиза в релиз. 

Поэтому ветка release/1.0.0 должна быть влита также в develop.

git checkout develop
git merge --no-ff release/1.0.0

Теперь ветка develop включает те же изменения.

Разработка продолжается, но на проде обнаружен баг — простая опечатка в тексте формы, которую совсем не хочется отправлять через долгий релизный цикл. Для быстрых правок в GitFlow применяются hotfix. Это ветки с префиксом hotfix, которые содержат незначительные исправления, создаются из прод-ветки master, по готовности сливаются с master и develop.

git checkout master
git checkout -b hotfix/release_1.0.0_textform_fix
...
git checkout master
git merge --no-ff hotfix/release_1.0.0_textform_fix
git checkout develop
git merge --no-ff hotfix/release_1.0.0_textform_fix

Актуальная хронология репозитория:

Основные ветки GitFlow

• master/main: содержит тестированный, стабильный код, который может быть выложен на прод.

• develop: основная ветка для разработки, содержит актуальный, но не релизный код.

• feature: ветки для разработки новых функциональностей, которые впоследствии сливаются с develop.

• release: ветка для подготовки новых релизов, отделяется от develop, затем сливается с master и develop.

• hotfix: ветки для быстрого исправления ошибок в продакшен-версиях, сливаются с master и develop.

Преимущества GitFlow

• Четкая структура управления версиями.

• Поддержка множественных параллельных релизов.

• Удобство в навигации по истории проекта.

Недостатки GitFlow

• Требует настройки правил для веток, CI/CD.

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

GitHub Flow

GitHub Flow — более простая и гибкая модель, разработанная для проектов, где главенствует принцип Continuous Integration. Модель предполагает создание новой ветки для каждой новой задачи, непрерывное тестирование при слиянии, а также постоянные/частые релизы без определенного релизного цикла.

Весь production-код содержится в ветке master. Для каждой новой фичи разработчик создает отдельную ветку от master. Одно из негласных правил данной модели — именовать ветки так, чтобы они описывали основную задачу фичи. При этом добавлять префикс feature (аналогично модели GitFlow) не обязательно.

git init
git checkout -b account_verification_by_email

По завершению работы создается PR — pull request (Merge Request в Gitlab), запрос на слияние веток. Это ключевая особенность модели, когда перед слиянием (merge) инструментами системы git создается запрос на ревью кода, а после есть возможность поднять автотесты, только при прохождении которых будет выполнен merge в master.

^{Изображение: docs.github.com}

^{Изображение: theserverside.com}

Основные ветки GitHub Flow

• main/master: единственная ветка, которая содержит стабильный код, готовый к развертыванию в продакшен.

Преимущества GitHub Flow

• Простота и понятность процесса.

• Быстрый цикл разработки и релизов.

• Идеально подходит для CI/ CD

Недостатки GitHub Flow

• Не подходит для проектов со сложными релизными циклами.

• Может быть рискованно для очень крупных проектов с множеством зависимостей.

kube

Trunk Based Development

Trunk Based Development (TBD) — это подход, при котором разработчики сливают изменения непосредственно в главную ветку (trunk/main/master), минимизируя количество параллельных веток. Это обеспечивает высокую скорость разработки, а также меньшее количество конфликтов при слиянии.

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

git init
git checkout -b account_verification_by_email_interface

С каждой последующей итерацией фича обрастает функционалом и никогда не будет ломать сборку. Trunk-ветка всегда содержит стабильный, готовый для релиза код, поэтому перед слиянием в trunk-ветку должны быть проведены тесты. После успешных тестов — слияние.

git checkout master
git merge --no-ff account_verification_by_email_interface

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

git checkout account_verification_by_email_complete
git tag complete

Граф веток и коммитов может выглядеть так:

Feature Flags

Для управления рисками и обеспечения контроля над новыми функциями, которые могут быть не полностью готовы к использованию всеми пользователями, в Trunk Based Development активно используются feature flags. Feature flags позволяют разработчикам включать или отключать функциональность без необходимости делать новые деплои. Таким образом, можно управлять доступом к новым функциям, проводить A/B тестирование, постепенное внедрение и сбор обратной связи от пользователей в реальных условиях эксплуатации.

Управление feature flags может осуществляться через различные платформы:

1. LaunchDarkly — один из лидеров рынка для управления feature flags, который предоставляет мощные инструменты для развертывания, тестирования, анализа функций в реальном времени.

2. Split.io — сервис, который помимо управления флагами предоставляет обширные возможности для проведения экспериментов, A/B тестирования.

3. ConfigCat — более простой и доступный инструмент, который подойдет для малых и средних проектов, предлагая базовые функции управления флагами и возможности развертывания.

Основные ветки TBD

• trunk/main/master: центральная ветка проекта, куда вносятся все изменения.

Преимущества TBD

• Упрощение процесса разработки, минимизация управленческой нагрузки.

• Ускорение цикла разработки за счёт частых коммитов в основную ветку.

• Легкость  внедрения непрерывной CI/CD.

Недостатки TBD

• Высокие требования к дисциплине разработчиков и качеству автоматических тестов.

• Риск внесения нестабильного кода в основную ветку.

• Может потребоваться дополнительное время на стабилизацию перед релизом.
  

Сравнение моделей

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

Для малых команд (примерно до 5 человек) и стартапов GitHub Flow часто является лучшим выбором, так как он прост в имплементации и поддерживает высокие темпы разработки с минимальными накладными расходами на управление ветками.

Для средних и крупных команд GitFlow или Trunk Based Development могут быть предпочтительнее, в зависимости от того, насколько критично управление множеством релизов и стабильность кода. GitFlow хорошо подходит для компаний с чёткими релизными циклами и необходимостью поддержки нескольких версий продукта одновременно.

Trunk Based Development может быть идеален для организаций, которые ставят на первое место быструю доставку и инновации, так как этот подход ускоряет процессы CI/CD.

Если ни один из известных вариантов не подходит — всегда можно разработать что-то свое, используя элементы из разных подходов. Главное, что именно культура разработки внутри команды определяет способ работы с системой git.

Подготовили для вас выгодные тарифы на облачные серверы

Что почитать и посмотреть

1. Подробнее про Gitflow: на английском, на русском.

2. Гайд про Git и модели ветвления от Atlassian. 

3. Больше про TBD от Avito на Хабре.

4. Видео с Gitcon 2023 на YouTube.