Git Flow или trunk-based: какую модель ветвления выбрать

Модель ветвления определяет, как код попадает от разработчика в релиз. Git Flow с долгими ветками develop и release подходит продуктам с редкими плановыми релизами и поддержкой нескольких версий. Большинству веб-продуктов удобнее trunk-based development: короткие ветки на один-два дня, частое слияние в основную ветку, автотесты на каждом изменении и флаги для незавершённых функций.

Разберём, чем отличаются модели, как они влияют на скорость и конфликты и что нужно, чтобы работать с короткими ветками.

Какие бывают модели ветвления?

Основные модели различаются количеством долгоживущих веток и тем, как часто код сливается в основную ветку.

Модель	Как устроена	Когда подходит
Git Flow	main, develop, ветки задач, release и hotfix	Редкие релизы, несколько поддерживаемых версий
GitHub Flow	main и короткие ветки задач через пулл-реквесты	Веб-продукты с частыми релизами
Trunk-based	Всё сливается в main несколько раз в день, флаги для незавершённого	Зрелый CI, частые релизы, несколько команд
Release branches	main плюс короткие ветки на время выпуска версии	Мобильные приложения, коробочные продукты

Почему долгие ветки замедляют разработку?

Долгие ветки копят расхождения с основным кодом. Чем дольше живёт ветка, тем больнее конфликты при слиянии, тем позже обнаруживаются несовместимости и тем больше изменений попадает в один рискованный релиз.

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

Фото: Unsplash

Как работать с короткими ветками?

Работа с короткими ветками требует трёх вещей: умения делить задачи на маленькие части, надёжных автотестов в CI и флагов функций, которые прячут незавершённое от пользователей. Без них частые слияния в основную ветку превращаются в постоянные поломки.

git switch -c feature/checkout-address-validation
# небольшое законченное изменение, тесты, коммит
git push -u origin feature/checkout-address-validation
# пулл-реквест → CI → ревью → слияние в main в тот же или на следующий день

Правила команды:

1. Ветка живёт не больше одного-двух дней.
2. Каждое слияние в main проходит CI и ревью.
3. Main всегда в состоянии, пригодном для релиза.
4. Незавершённые функции — под выключенным флагом, подробнее в статье feature flags.
5. Большие изменения делятся на шаги: подготовка, новая логика, переключение, удаление старого.

Когда Git Flow всё ещё уместен?

Git Flow уместен, когда релизы редкие и плановые, а несколько версий продукта поддерживаются одновременно: коробочное ПО, библиотеки, системы с обязательным приёмочным тестированием у заказчика. Там отдельная релизная ветка помогает стабилизировать версию, пока разработка продолжается.

• коробочные продукты и библиотеки с поддержкой нескольких версий;
• длительное приёмочное тестирование перед каждым релизом;
• регулируемые отрасли с формальной процедурой выпуска версий.

Для веб-продукта с ежедневными релизами Git Flow обычно лишний: ветка develop становится вторым main, а релизные ветки добавляют ручную работу.

Как выбрать модель для команды?

Выбирайте модель по частоте релизов и зрелости автоматизации. Если CI ненадёжен, а тестов мало, сначала вкладывайтесь в них — иначе ни одна модель не даст быстрых и безопасных релизов.

• веб-продукт, релизы несколько раз в неделю — GitHub Flow или trunk-based;
• мобильное приложение — main плюс короткие релизные ветки;
• коробочный продукт с несколькими версиями — Git Flow или его упрощение;
• в любом случае — защищённая основная ветка, обязательный CI и ревью.

Подробнее о пайплайнах и тестах — статьи CI/CD на GitHub Actions и какие автотесты нужны продукту.

Коротко

• Git Flow — долгие ветки и плановые релизы, trunk-based — частые слияния в main.
• Долгие ветки копят конфликты и превращают релизы в рискованные.
• Короткие ветки требуют маленьких задач, надёжного CI и флагов функций.
• Git Flow уместен для коробочных продуктов с несколькими версиями.
• Веб-продуктам обычно лучше подходит GitHub Flow или trunk-based development.