Что такое Git Flow, GitHub Flow и Trunk-based development?
Git Flow, GitHub Flow и Trunk-based development — это стратегии ветвления (branching strategies), определяющие, как команда работает с ветками Git в контексте CI/CD: когда создавать ветки, как их именовать, когда и куда сливать.
Представьте три ресторана с разной организацией кухни. Git Flow — это ресторан с высокой кухней: строгая иерархия (шеф, су-шеф, повара по станциям), блюдо проходит множество этапов проверки, выход долгий, но контролируемый. GitHub Flow — это современное бистро: одна основная линия подачи, каждый повар готовит блюдо от начала до конца и ставит на раздачу после проверки шефом. Trunk-based — это фастфуд: все работают на одной линии, каждое блюдо готово за минуты, но нужна железная дисциплина и стандартизация рецептов.
1. Git Flow
Классическая модель с долгоживущими ветками:
main(master) — production-код, каждый коммит = релиз.develop— интеграционная ветка, текущая разработка.feature/*— ветки для новой функциональности (отdevelop, вливаются вdevelop).release/*— подготовка релиза (отdevelopвmain).hotfix/*— срочные исправления production (отmain, вливаются вmainиdevelop).
Плюсы: строгая организация, подходит для планового релизного цикла. Минусы: сложность, долгоживущие ветки приводят к конфликтам, медленная интеграция (противоречит CI).
2. GitHub Flow
Упрощённая модель:
main— всегда deployable (готов к деплою).feature/*— короткоживущие ветки отmain.- Workflow: создать ветку -> разработка -> Pull Request -> Code Review -> Merge в
main-> Deploy.
Плюсы: простота, быстрая интеграция, хорошо сочетается с CI/CD. Минусы: нужна хорошая автоматизация тестов и деплоя; нет понятия «релизной ветки».
3. Trunk-based Development
Вся работа ведётся в одной ветке (main/trunk):
- Разработчики коммитят напрямую в
main(или через очень короткоживущие ветки — не более 1-2 дней). - Используются feature flags для скрытия незавершённой функциональности.
- Релиз-ветки создаются от
mainпри необходимости.
Плюсы: максимально частая интеграция, минимум конфликтов, лучше всего для CI. Минусы: требует высокой дисциплины, мощного набора тестов и инфраструктуры feature flags.
Сравнение стратегий
| Критерий | Git Flow | GitHub Flow | Trunk-based |
|---|---|---|---|
| Количество долгоживущих веток | 2 (main, develop) |
1 (main) |
1 (main) |
| Время жизни feature-ветки | Дни-недели | Часы-дни | Часы (или без ветки) |
| CI/CD совместимость | Низкая | Высокая | Максимальная |
| Сложность | Высокая | Низкая | Средняя (дисциплина) |
| Feature flags | Не обязательны | Не обязательны | Обязательны |
| Применимость | Плановые релизы, legacy | Большинство проектов | Зрелые команды, микросервисы |
Рекомендации для CI/CD
- Git Flow — для проектов с фиксированным релизным циклом (раз в месяц/квартал), когда нужна строгая изоляция релизов.
- GitHub Flow — для большинства проектов, особенно микросервисов с частым деплоем.
- Trunk-based — для зрелых команд с высокой культурой тестирования и feature flags.
Вывод
В банковской среде чаще используется GitHub Flow (баланс простоты и контроля) или Git Flow (из-за регуляторных требований к релизам). Trunk-based development набирает популярность в командах, практикующих DevOps и микросервисную архитектуру.
На собеседовании: важно не просто перечислить стратегии, а объяснить, почему Git Flow плохо сочетается с CI — долгоживущие ветки нарушают принцип «частой интеграции». Покажите, что вы понимаете trade-off между контролем (Git Flow) и скоростью (Trunk-based).