Git Flow, GitHub Flow и Trunk-Based Development: какой workflow выбрать

Когда команда только начинает использовать Git, все коммитят в main — и это работает. Но с ростом числа разработчиков, выпусков и параллельных задач хаос нарастает: кто-то сломал сборку, хотфикс застрял в незарелизенной ветке, никто не знает, что попадёт в следующий релиз. Решение — договориться о workflow: наборе правил, как создавать ветки, когда сливать и что идёт в прод.

Существует несколько устоявшихся подходов: Git Flow, GitHub Flow, Trunk-Based Development и GitLab Flow. У каждого свои сильные стороны и ограничения. Разберём, чем они отличаются и какой выбрать для вашей команды.

Эта статья — часть нашего полного путеводителя по Git. Там — весь маршрут: от первого коммита до продвинутых workflow.

Git Flow: строгая структура для долгих релизов

Git Flow — самый известный workflow, описанный Винсентом Дриссеном в 2010 году. Его основа — две постоянные ветки: main (всегда стабильна, только теги релизов) и develop (интеграционная ветка). Поверх них — три типа временных веток.

			main          ●─────────────────────────────────●─── (v1.1.0)
               \                               /|
develop        ●───●───●───●───●───●───●───●──● ●──(hotfix merge)
                    \       /       \   /      \
feature/login  ─────●───●──           \        \
feature/pay    ─────────────────●───●─\        \
release/1.1.0                         ●───● ──→ main+develop
                                               \
hotfix/crash   ────────────────────────────────●───● ──→ main+develop
		

• feature/* — новые функции, ответвляются от develop, сливаются обратно
• release/* — подготовка релиза: только баг-фиксы, документация, версии; сливается в main и develop
• hotfix/* — срочные фиксы прямо из main; сливается и в main, и в develop

Когда оправдан: мобильная разработка (App Store review занимает дни), коробочное ПО с поддержкой нескольких версий, enterprise-продукты с квартальными релизными циклами. Команда знает: в main только то, что уже у пользователей.

Минусы: тяжёлый для SaaS с деплоем несколько раз в день — слишком много веток, слишком много merge'ей. Ветки живут долго, накапливают конфликты. Инструмент git flow упрощает работу, но не убирает сложность модели.

GitHub Flow: простота для непрерывной поставки

GitHub Flow появился как реакция на сложность Git Flow. Правило одно: main всегда готов к деплою, новые фичи — в короткоживущих ветках через PR.

			main     ●──────────────────────●──────────────●
          \                   /  \            /
feature   ─●──●──●──●──●──●──    ─●──●──●──●─
                               PR              PR
		

• Создаёте ветку от main с понятным именем (fix/login-timeout, feat/dark-mode)
• Коммитите, открываете Pull Request — это точка обсуждения и code review
• После approve'а и прохождения CI — мёрж в main и деплой

Когда оправдан: SaaS-продукты, веб-сервисы, команды с настроенным CI/CD, где деплой происходит после каждого мёрж в main. Простота модели снижает когнитивную нагрузку: все знают один набор правил.

Ограничение: отсутствует встроенная концепция «релиза» и «staging». Если нужно поддерживать несколько версий одновременно — GitHub Flow не покрывает этот кейс без дополнительных договорённостей.

Trunk-Based Development: всё в main, feature flags в помощь

Trunk-Based Development (TBD) доводит идею короткоживущих веток до предела — разработчики интегрируют изменения напрямую в trunk несколько раз в день. Модель существует с 1990-х и вдохновила упрощённые подходы вроде GitHub Flow. Если используются ветки — они живут максимум 1–2 дня и сливаются без церемоний.

			main  ●──●──●──●──●──●──●──●──●──●──●──●──●──●
       |     |        |              |       |
       dev1  dev2     dev3           dev1    dev2
       (feat A half-done,
        behind feature flag)
		

Незавершённый код скрывается за feature flags: функция есть в коде, но включается только для нужной аудитории. Это позволяет постоянно интегрировать изменения, не ломая прод. Системы вроде LaunchDarkly, Unleash или простейший конфиг-файл — стандартный инструментарий TBD-команд.

Когда оправдан: зрелые команды с высоким покрытием тестами, быстрым CI (< 10 минут), культурой маленьких атомарных коммитов. Google, Facebook, Amazon деплоят по этой модели тысячи раз в день. По данным DORA (State of DevOps 2018), элитные DevOps-команды деплоят в 46 раз чаще, чем команды с низкой зрелостью процессов.

Требования: без надёжного CI/CD, автотестов и feature flags TBD превращается в хаос. Не пробуйте этот подход, если CI занимает больше 20 минут или нет хорошего тестового покрытия — нет универсального порога, но без него TBD рискован.

GitLab Flow: среднее между двух крайностей

GitLab Flow решает главный пробел GitHub Flow — отсутствие environment-веток. Концепция: main — это то, что разработано; staging — что протестировано; production — что в проде.

			main       ●──●──●──●──●──●──●──●
             \        \        \
staging        ●────────●────────●
                \        \        \
production       ●────────●────────●
		

Фичи разрабатываются в ветках, сливаются в main, затем промоутируются вниз по цепочке окружений. Подход близок к реальности большинства команд: есть staging для QA, есть production для пользователей.

Когда оправдан: команды, которым нужен staging/QA-процесс перед релизом, но сложность Git Flow избыточна. Хорошо сочетается с GitLab CI/CD и авто-деплоем по веткам.

Таблица сравнения

Как выбрать: практические рекомендации

Начните с GitHub Flow — это разумный дефолт для большинства команд. Простые правила, понятный процесс PR/review, легко объяснить новичку. Если вы только выстраиваете процессы — это ваш выбор.

Переходите на Trunk-Based Development, когда: CI стабильно проходит за < 10 минут, команда привыкла к маленьким коммитам, есть инфраструктура для feature flags. Не форсируйте переход — команды, прыгнувшие в TBD без готовности, возвращаются обратно через месяц.

Выбирайте Git Flow только если у вас длинные релизные циклы с обязательной сертификацией, поддержка нескольких мажорных версий одновременно (например, мобильное приложение с 1.x и 2.x у разных клиентов), или регуляторные требования к freeze-периодам.

Помните: workflow — это договорённость внутри команды. Лучший workflow — тот, который все понимают и соблюдают. Формализованный Git Flow, который никто не соблюдает, хуже неформального «коммитим в main аккуратно». Также полезно настроить Git hooks для автоматической проверки соблюдения правил — linting, тесты, формат коммит-сообщений.

Git workflow — не религия. GitHub Flow подходит большинству команд прямо сейчас: он прост, понятен и хорошо масштабируется с CI/CD. Trunk-Based Development — следующий уровень для команд, которые хотят деплоить несколько раз в день и готовы инвестировать в инфраструктуру. Git Flow остаётся правильным выбором там, где он исторически появился — в продуктах с длинными релизными циклами. Выбирайте инструмент под задачу, а не под моду.