Стратегии ветвления: GitFlow, GitHub Flow, trunk-based

Git ничего не знает про «релизные ветки» или «фича-флаги». В нём есть только коммиты и указатели на них (branch). Любая «стратегия» - это набор человеческих правил поверх:

• какие ветки бывают (main, develop, release/*, feature/*);
• как они называются;
• кто может в них коммитить;
• когда и куда сливать;
• что значит «релиз».

Эти правила можно расставить четырьмя способами:

1. Никак. Все делают, как привыкли. Через полгода в репо сорок веток с непонятным статусом, в main лежит код, который нельзя задеплоить, и никто не знает, какой коммит сейчас на продакшене.
2. GitFlow. Жёсткий каркас из четырёх типов веток. Подходит для продуктов с долгими циклами и параллельными версиями.
3. GitHub Flow. Одна вечная ветка main плюс короткие фича-ветки. Подходит для SaaS, где «релиз» - это «деплой».
4. Trunk-based. Все коммитят в main (или почти все), ветки живут часами. Опирается на CI и feature flags.

Эти три модели - не «уровни зрелости» и не «правильный→неправильный». Это три разных решения под три разных контекста. Выбор делается один раз, фиксируется в CONTRIBUTING.md, и команда держится выбранного. Хуже всех живут команды, у которых стратегия не выбрана: каждый делает «по интуиции», и история - компот из несовместимых подходов.

Ниже разберём все три по очереди, и в конце - как выбрать.

Описан Vincent Driessen в 2010 году в статье «A successful Git branching model». На несколько лет стал отраслевым стандартом де-факто - настолько, что даже появился плагин git flow с командами git flow feature start, git flow release finish и прочими. Идея - формализовать всё, оставив минимум места для разнобоя.

Ветки в GitFlow:

main      ← только релизы, в каждый коммит - тег версии

develop   ← следующая версия в разработке

feature/* ← фичи, ветвятся от develop, мерджатся в develop

release/* ← подготовка релиза: bugfix, обновление версии

hotfix/*  ← срочный фикс из main, мерджится и в main, и в develop

Жизненный цикл фичи:

develop → feature/login → develop

Жизненный цикл релиза:

develop → release/1.4 → main (тег v1.4.0) + обратно в develop

Жизненный цикл хотфикса:

main → hotfix/critical-bug → main (тег v1.4.1) + обратно в develop

main в GitFlow - это только прошлые релизы. Туда ничего не попадает напрямую, только через release/* или hotfix/*. «Текущее состояние разработки» живёт в develop. У main и develop всегда есть гэп: они сходятся в момент релиза.

Это даёт жёсткую двухлинейную историю. По графу видно: вот релизы, вот разработка, вот срочные фиксы.

# Стартуем фичу

git switch -c feature/login develop

# ... разработка, коммиты ...

# Мерджим обратно в develop

git switch develop

git merge --no-ff feature/login

# Готовим релиз

git switch -c release/1.4 develop

# ... финальные правки, bump версии ...

# Финиш релиза

git switch main

git merge --no-ff release/1.4

git tag -a v1.4.0 -m "release 1.4.0"

git switch develop

git merge --no-ff release/1.4

--no-ff (--no-fast-forward, см. fast-forward) тут обязателен: даже если fast-forward возможен, создаётся merge-коммит, чтобы факт «здесь была ветка» оставался в истории.

Где GitFlow родной:

• Продукты, которые поставляются в виде версий (мобильные приложения в App Store/Play Store, desktop-софт, embedded).
• Несколько релизных линий одновременно (v1.4, v1.5, v2.0 живут параллельно, в каждую идут свои хотфиксы).
• Длинный цикл подготовки релиза с фазой стабилизации.

Где GitFlow ломается:

• Web и SaaS, где деплой каждый час. Релиз-ветки тут - это бюрократия без пользы; main и develop всегда расходятся, и операция «слить релиз» превращается в постоянный геморрой.
• Команды меньше десяти человек. Накладные расходы на пять типов веток не окупаются.
• CI, где каждый PR - кандидат на деплой. GitFlow добавляет целый этап «через release/*», который для непрерывной поставки не нужен.

Сегодня GitFlow в чистом виде используют редко. Чаще встречается его упрощённый вариант: main + develop + feature/*, без release/* и hotfix/*. Это уже на полпути к GitHub Flow.

Сам Driessen в 2020 году опубликовал апдейт: «GitFlow проектировался под software with explicit version releases; для continuously delivered web - берите модель попроще». Полезное напоминание, что даже автор не пытался выдать модель за универсальную.

Реакция на сложность GitFlow и одновременно отражение того, как устроены команды, которые деплоят несколько раз в день. Описана Scott Chacon (один из основателей GitHub) в 2011 году.

Правила:

1. main всегда деплоима. Любой коммит в main можно выкатить на прод.
2. Чтобы что-то изменить - создай ветку от main с осмысленным именем (feat/..., fix/...).
3. Коммить туда, пушь, открывай Pull Request (pull-request).
4. Получай ревью (code-review), правь.
5. Когда зелёный CI и есть аппрув - мерджи в main.
6. Из main деплой автоматически (или почти).

Всё. Никаких develop, release/*, hotfix/*. Если нужен срочный фикс - это просто короткая ветка от main, как любая другая. Если нужно «отложить релиз» - этого нельзя, релиз непрерывный.

Главное требование к main: всегда зелёная и деплоима. Если кто-то смерджил коммит, который ломает прод, это не «вернёмся через две недели на release/», а «откатить или починить прямо сейчас». Поэтому GitHub Flow намертво завязан на:

• сильный CI - все тесты гоняются на каждом PR;
• branch protection на main - без зелёного CI и аппрувов мердж невозможен;
• быстрые тесты - иначе мерджить будет страшно.

Размер ветки: от нескольких часов до нескольких дней. Не недели. Если фича большая - нарезается на серию мелких PR, каждый из которых самостоятелен и не ломает прод.

git switch main

git pull --ff-only

git switch -c feat/email-notifications

# ... несколько коммитов ...

git push -u origin feat/email-notifications

# Открыть PR на GitHub, пройти ревью, дождаться зелёного CI

# Кнопка «Merge» - обычно через squash или rebase merge

# (см. главу 8)

git switch main

git pull --ff-only

git branch -d feat/email-notifications

Где GitHub Flow родной:

• SaaS, веб-приложения, API-сервисы.
• Команды от 3 до ~50 человек.
• CI/CD на каждый PR.
• Один production environment без «версий», только «текущее состояние».

Где GitHub Flow ломается:

• Параллельные версии (нужно поддерживать v1.x после релиза v2.0). Тут одной ветки не хватает, появляются support/v1.x, и стратегия мигрирует ближе к GitFlow.
• Очень крупные команды (>100), где даже короткие ветки начинают конфликтовать друг с другом. Там лучше работает trunk-based.
• Регулируемые отрасли с жёсткими релизными процедурами (медицина, финансы, госсектор). Здесь «релиз = событие» с подписями и аудитом, и непрерывная поставка не подходит.

GitHub Flow - самая распространённая стратегия в 2020-х. Если вы открываете новый проект и не знаете, что выбрать, - берите GitHub Flow. Это не оптимум, это разумный дефолт.

Логическое продолжение GitHub Flow: «если ветка живёт максимум несколько часов, а лучше - несколько минут, то зачем она нужна?»

В trunk-based development разработчики коммитят прямо в main (англ. «trunk» - ствол), либо в очень короткие ветки длиной <1 дня. История main - это поток коммитов от всех, без выделенных feature-веток.

Сегодня:   * Alice: refactor parser

           * Bob:   add metric for /api/users

           * Alice: fix off-by-one in pagination

           * Carol: extract helper for date math

           * Bob:   wire up new metric in dashboard

Каждый коммит - самостоятельная единица. Если что-то на проде сломалось -git revert <sha>. Никаких длинных PR.

Главный вопрос: «А как же незаконченные фичи? Я неделю писал новый раздел, он не работает в середине». Ответ -feature flags:

if feature_enabled("new_billing_page", user):

    return new_billing_view(user)

return legacy_billing_view(user)

Код новой страницы биллинга попадает в main и едет на прод каждый день. Но флаг new_billing_page выключен у всех. Когда разработка закончится - флаг включается сначала на 1% пользователей, потом на 10%, потом на 100%. Когда стабилизировалось - флаг и legacy-ветка кода удаляются.

Trunk-based опирается на четыре столпа:

1. CI с быстрыми тестами. В идеале -<10 минут от коммита до «зелёное». Без этого никто не будет коммитить в main.
2. Feature flags. Не одна-две, а инфраструктура: панель управления, постепенные выкатки, метрики по флагу.
3. Возможность отката за минуты. Деплой автоматизирован, откат тоже.
4. Культура мелких изменений. Большие фичи нарезаются на десятки мелких коммитов, каждый из которых проходит CI и деплоится.

Где trunk-based родной:

• Большие команды (>50 человек). Здесь длинные ветки гарантируют merge hell. Лучше много мелких коммитов в main, чем десять веток, которые расходятся всё дальше.
• Команды с зрелым CI/CD и feature-flag платформой.
• Продукты, где «эксперимент» - часть процесса (A/B тесты, ML, rollout по сегментам).

Поэтому trunk-based используют Google, Facebook, Stripe, Shopify - и почти любая крупная вэб-компания. Это не «модно», это следствие того, что иначе на таком масштабе не работается.

Где trunk-based ломается:

• Без CI. Если автотесты гоняются ночью, в main будет лежать нерабочий код по 12 часов в сутки.
• Без feature flags. Без них разработчик не может «положить в main недоделанную фичу», и придётся вернуться к веткам.
• В маленьких командах без необходимости. Trunk-based - это накладные расходы на инфраструктуру. Если у вас три человека и один деплой в неделю - GitHub Flow проще и достаточен.

Trunk-based - это не «коммитьте без ревью». Ревью никуда не девается, оно происходит просто иначе: либо через короткие PR с быстрым аппрувом, либо через post-commit review (правка зашла, но коллега посмотрел в течение дня).

На бумаге feature flag выглядит элегантно. На практике у каждого флага есть цена:

• Развилка кода. В одной части файла -if flag_on: new else: old. Полгода спустя кто-то трогает блок, не понимает, какая ветка живая, ломает обе.
• Тестирование на N²: теперь нужно тестировать комбинации флагов. Десять флагов - тысяча комбинаций. На практике тестируется три-четыре, остальные - на удачу.
• «Вечные флаги». Флаг включили на 100%, забыли удалить. Через год это уже не flag, это техдолг.

Trunk-based требует уметь добавлять флаг и уметь его удалять (это разные навыки). Без второго накапливается код-помойка.

Полезная практика -жизненный цикл флага:

1. Создан, выключен у всех.
2. Включён у разработчиков (внутренний дог-фуд).
3. Постепенный rollout: 1%, 10%, 50%, 100%.
4. Зафиксирован. Через 2 недели после 100% - pull request, который удаляет флаг и старую ветку кода.

Если шаг 4 не происходит автоматически или через регулярную ревизию - flag-долг растёт линейно числу новых фич.

Выбранная стратегия определяет, как устроен CI и деплой.

GitFlow:

feature/* → CI (тесты + линт)

develop   → CI (тесты + интеграционные) + деплой на staging

release/* → CI (полный регресс) + деплой на pre-prod

main      → CI + деплой на production по тегу

CI устроен пирамидой: чем «выше» ветка, тем больше тестов. Деплой привязан к merge в определённую ветку. Релизы - это события, а не побочный эффект мержа.

GitHub Flow:

feature/* → CI (всё, что есть) + preview-окружение

main      → CI + автоматический деплой в production

CI и деплой одинаковые для всех веток. PR-окружение (preview) позволяет посмотреть фичу до мержа. После мержа в main - автоматический деплой.

Trunk-based:

main      → CI + автоматический деплой в production

            feature flags решают, что включено для кого

У всех коммитов один путь: тесты → деплой → флаги. Никаких preview-окружений на ветку - потому что нет долгих веток. «Превью» - это «включить флаг для тестового аккаунта на проде».

Чем правее по этой шкале, тем больше требуется от инфраструктуры деплоя. CI/CD не «прикладывается» к стратегии - оно её и определяет. Команда, у которой нет автоматического деплоя, не сможет жить в trunk-based, даже если очень хочет.

Размер команды грубо предсказывает, какая стратегия выживет:

Это не строгие границы. Команда из десяти человек может успешно жить в trunk-based, если у них хороший CI и зрелая культура. Команда из ста может работать в GitHub Flow, если у них дисциплина и приоритет - короткие PR.

Но есть закономерность: чем больше людей, тем дороже длинные ветки. Конфликт мержа двух людей решается за полчаса. Конфликт мержа десяти веток между собой - это уже отдельная работа на несколько дней. Trunk-based - это решение не «удобства», а математики: при росте команды стоимость длинных веток растёт быстрее линейного.

Алгоритм:

1. Поставляешь версии? (мобильное приложение, desktop, embedded, on-premise enterprise) - GitFlow или его упрощённый вариант.
2. SaaS / API / веб с непрерывным деплоем? - GitHub Flow по умолчанию.
3. Команда >50 человек и есть CI/CD + feature flags? - trunk-based.
4. Не уверен? - GitHub Flow. Это разумный дефолт, который потом легко мигрировать в любую сторону.

Зафиксируй выбор в CONTRIBUTING.md:

## Branching

We use GitHub Flow:

-main is always deployable

-feature work happens in short-lived branches (≤3 days)

-all changes go through pull requests with ≥1 approval

-main is protected: no direct pushes, no force pushes

Long-lived branches (release/*, develop) are NOT used.

Эти десять строк экономят месяцы недопониманий. Новый человек видит правила сразу, без необходимости спрашивать «а как у вас?»

Что НЕ делать:

• Не миксуй стратегии в одном репо. «У нас иногда GitFlow, а иногда trunk-based» - это «у нас нет стратегии».
• Не выбирай «потому что Google так делает». Google так делает, потому что у них 50 000 разработчиков. У тебя три. Контекст разный.
• Не переходи с одной стратегии на другую «между прочим». Это требует отдельного решения, переучивания и обычно - отдельной миграционной фазы.
• Не пытайся улучшить GitFlow «своими дополнениями». Если кажется, что нужны ещё ветки сверху - скорее всего, ты пытаешься компенсировать что-то ещё (плохой CI, отсутствие owners, нехватка staging-окружения).

Один из верных признаков «вы выбрали неудачную стратегию»: мерж в main ощущается рискованным. Если все боятся мержить, и от этого PR копятся неделями - стратегия не подходит к команде или продукту. Простое решение - упрощать (меньше веток, короче PR), не усложнять.

Промежуточный случай - продукт, который в основном живёт по GitHub Flow, но иногда нужен «релиз с подписью» (например, обновление прошивки или клиента, которое выкатывается раз в месяц всем разом).

Здесь подходит release train: ежемесячно (или по фиксированному расписанию) от main отрезается ветка release/2025-05, на ней делается финальная стабилизация (только bugfix, никаких новых фич), потом тег и подпись. После релиза ветка живёт ещё месяц на случай экстренного фикса, потом замораживается.

Это не GitFlow: нет develop, нет постоянных release/*. Это GitHub Flow + cut-and-freeze раз в период. Близко по духу к тому, как живут Chrome, Firefox, Node.js.

Полезно, когда часть пользователей хочет «стабильную версию ежемесячно», а часть -«всегда последнее». Тогда ежемесячные tag-релизы - это для первых, а main - для вторых.