GitFlow, GithubFlow, TBD: выбираем модель ве

Материал подготовлен командой Simple-Server для администраторов VPS и выделенных серверов. Команды и пути проверяйте на тестовой машине перед production.

Кратко о задаче

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

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

master/main: содержит тестированный, стабильный код, который может быть выложен на прод.
develop: основная ветка для разработки, содержит актуальный, но не релизный код.
feature: ветки для разработки новых функциональностей, которые впоследствии сливаются с develop.
release: ветка для подготовки новых релизов, отделяется от develop, затем сливается с master и develop.
hotfix: ветки для быстрого исправления ошибок в продакшен-версиях, сливаются с master и develop.

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

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

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

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

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

Четкая структура управления версиями.
Поддержка множественных параллельных релизов.
Удобство в навигации по истории проекта.

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

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

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

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

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

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

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.

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

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

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

Простота и понятность процесса.
Быстрый цикл разработки и релизов.
Идеально подходит для CI/ CD

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

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

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

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

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

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

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

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

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

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

LaunchDarkly — один из лидеров рынка для управления feature flags, который предоставляет мощные инструменты для развертывания, тестирования, анализа функций в реальном времени.
Split.io — сервис, который помимо управления флагами предоставляет обширные возможности для проведения экспериментов, A/B тестирования.
ConfigCat — более простой и доступный инструмент, который подойдет для малых и средних проектов, предлагая базовые функции управления флагами и возможности развертывания.

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

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

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

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

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

Упрощение процесса разработки, минимизация управленческой нагрузки.
Ускорение цикла разработки за счёт частых коммитов в основную ветку.
Легкость внедрения непрерывной CI/CD.

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

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

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

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

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

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

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

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

Критерий	GitFlow	GitHub Flow	Trunk Based Development (TBD)
Размер команды	Лучше подходит для больших команд	Хорошо работает для команд любого размера	Идеален для средних и больших команд
Релизные циклы	Длинные, с предварительными релизами (staging)	Короткие, релизы могут быть частыми и быстрыми	Очень короткие, непрерывные релизы
Сложность фичей	Поддерживает сложные фичи, требующие длительной разработки	Лучше подходит для простых или средней сложности фич	Подходит для простых и модернизированных фич
Зависимости фичей	Управление зависимостями через разные ветки	Фичи должны быть относительно независимы	Фичи должны быть независимы или использовать feature flags для управления зависимостями
Опытность команды	Подходит для команд с любым уровнем опыта, но требует хорошей документации процесса внутри команды	Простое управление, подходит для команд с любым уровнем опыта	Требует дисциплины CI/CD и комфорта с непрерывной интеграцией

Лучше подходит для больших команд

Хорошо работает для команд любого размера

Идеален для средних и больших команд

Длинные, с предварительными релизами (staging)

Короткие, релизы могут быть частыми и быстрыми

Очень короткие, непрерывные релизы

Поддерживает сложные фичи, требующие длительной разработки

Лучше подходит для простых или средней сложности фич

Подходит для простых и модернизированных фич

Управление зависимостями через разные ветки

Фичи должны быть относительно независимы

Фичи должны быть независимы или использовать feature flags для управления зависимостями

Подходит для команд с любым уровнем опыта, но требует хорошей документации процесса внутри команды

Простое управление, подходит для команд с любым уровнем опыта

Требует дисциплины CI/CD и комфорта с непрерывной интеграцией

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

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

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

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

Нужен сервер для практики? Арендуйте VPS/VDS в России — root-доступ, NVMe, DDoS-защита и поддержка 24/7.

GitFlow, GithubFlow, TBD: выбираем модель ветвления

Кратко о задаче

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

VPS для проекта

StarterVDS

PerformanceVDS

GitFlow, GithubFlow, TBD: выбираем модель ветвления

Кратко о задаче

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

VPS для проекта

StarterVDS

PerformanceVDS

Читайте также