Git не навязывает процесс: ветки дешёвые, делай что хочешь. Поэтому каждая команда выбирает модель ветвления — соглашение о том, какие ветки живут в проекте, откуда ветвиться и куда вливаться. Моделей за пятнадцать лет придумано много, но реально выбор идёт между тремя. Знать их нужно и чтобы быстро включиться в процесс новой команды, и чтобы понимать, почему процессы такие разные.
Git Flow: тяжеловес эпохи релизов
Классика 2010 года: две долгоживущие ветки — main (только релизы, каждый помечен тегом) и develop (интеграция текущей разработки) — плюс три вида временных: feature/* (от develop, в develop), release/* (подготовка релиза: стабилизация, версии), hotfix/* (срочный фикс от main, вливается и в main, и в develop).
Сильная сторона — параллельные версии: пока develop копит v2.4, release-ветка стабилизирует v2.3, а hotfix чинит v2.2 в проде. Слабая — церемониальность: много веток, много слияний, забытый «hotfix в develop» — классический источник регрессий.
Где уместен: коробочные продукты, мобильные приложения с релизными поездами, энтерпрайз с параллельной поддержкой версий. Для непрерывно деплоящихся веб-сервисов Git Flow сегодня — оверкилл (это признал и его автор).
GitHub Flow: просто и вокруг PR
Одна долгоживущая ветка — main, всегда готовая к деплою. Всё остальное — короткие ветки от main, вливаемые назад через pull request с ревью и зелёным конвейером. Влил — задеплоил.
Сильные стороны: минимальная церемония, скорость, естественная связка с код-ревью и CI. Слабость — нет штатного места для «стабилизации релиза» и параллельных версий: main всегда один.
Где уместен: веб-сервисы и команды с непрерывной поставкой — то есть большинство современных продуктовых команд. Если сомневаетесь, с чего начать, — начните с этого.
Trunk-based: скорость на пределе
Радикальное развитие той же идеи: все коммитят в main («ствол») очень маленькими порциями — либо напрямую, либо через ветки-однодневки. Интеграция происходит непрерывно, конфликты почти исчезают (нечему расходиться), скорость поставки максимальна.
Цена — зрелость инженерной культуры. Недоделанные фичи попадают в main и прячутся за фиче-флагами (код в проде, но выключен конфигом); без сильного автотестирования и дисциплины trunk-based превращается в хаос. Зато именно эта модель коррелирует с элитными показателями DORA-метрик — исследования доставки ПО стабильно связывают короткоживущие ветки с высокой скоростью и стабильностью.
Где уместен: команды с развитым CI, быстрым ревью и автотестами; крупные инженерные организации (Google живёт на монорепе со стволом).
Как выбирать
Вопросы, решающие выбор:
- Сколько версий поддерживаете одновременно? Несколько — Git Flow (или его release-часть). Одну, в проде всегда свежая — GitHub Flow / trunk-based.
- Как часто деплоите? Релизные поезда раз в месяц терпят церемонии; деплой по многу раз в день требует лёгкой модели.
- Насколько зрелы автотесты и ревью? Trunk-based без них опасен; GitHub Flow — рабочая середина.
И главное: модель — командное соглашение, а не догма. Реальные процессы часто гибридны («GitHub Flow плюс release-ветка перед мажорной версией») — важно, чтобы соглашение было явным и одинаково понималось всеми. Как ветвление стыкуется с конвейером доставки и версионированием — в статье про ветки и релизный цикл.
Коротко
- Git Flow: main+develop+feature/release/hotfix — для параллельных версий и релизных поездов; для непрерывного деплоя избыточен.
- GitHub Flow: один main + короткие ветки через PR — дефолт современных продуктовых команд.
- Trunk-based: мини-порции в ствол + фиче-флаги — максимальная скорость при зрелых тестах и культуре.
- Выбор определяют: число поддерживаемых версий, частота деплоя, зрелость автоматизации.
- Модель — явное командное соглашение; гибриды нормальны.
Что почитать дальше
- Ветки и релизный цикл — продолжение темы на стороне CI/CD: версии, теги, GitOps.
- Pull request и код-ревью — механика, на которой стоят GitHub Flow и trunk-based.
- CI/CD-конвейер — автоматика, делающая лёгкие модели возможными.