Git Flow: что это такое, модель ветвления и использование в проектах

Что такое Git Flow?

Git Flow — это модель ветвления Git, которая задаёт строгую структуру веток и правил слияния для управления разработкой, релизами и исправлениями. Vincent Driessen опубликовал статью «A successful Git branching model» в январе 2010 года, и с тех пор Git Flow стал стандартом де-факто в корпоративной Java и .NET разработке. Основная идея — разделить код на пять типов веток с разным уровнем стабильности.

По данным Atlassian Git Tutorials, 2024, Git Flow основан на двух бессрочных ветках: main (ранее master) и develop. Все остальные ветки — временные: feature, release, hotfix. Каждый тип ветки имеет чётко определённый lifecycle и правила слияния. В мобильной разработке Git Flow применяется в проектах с регулярными релизными циклами (2–4 недели) и поддержкой нескольких версий.

Git Flow отличается от простых моделей (GitHub Flow) тем, что требует отдельной ветки develop для интеграции. Это добавляет один шаг в процесс слияния, но обеспечивает дополнительную изоляцию незавершённых фич от готового к релизу кода.

Vincent Driessen и история Git Flow

В 2010 году Vincent Driessen опубликовал пост «A successful Git branching model», который стал одним из самых цитируемых в истории Git. Модель была создана для проекта с фиксированными релизами и параллельной поддержкой версий. В 2020 году Driessen признал, что Git Flow устарел для современных CI/CD-практик, но модель остаётся актуальной для проектов с длинным релизным циклом и необходимостью поддержки старых версий.

# Инициализация Git Flow
git flow init

# Создание feature-ветки
git flow feature start "add-auth"

# Завершение feature-ветки (слияние в develop)
git flow feature finish "add-auth"

# Создание release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main ветка: релизный код и тегирование

Main (ранее master) — основная ветка, содержащая только релизный код, готовый к развёртыванию. Каждый коммит в main должен соответствовать определённой версии продукта, помеченной тегом (tag) в формате семантического версионирования, например v1.0.0, v1.1.0. Никакая прямая разработка в main не ведётся — изменения попадают сюда только через release или hotfix ветки.

По данным semver.org, 2024, теги в main используют формат MAJOR.MINOR.PATCH. MAJOR увеличивается при несовместимых изменениях API, MINOR — при добавлении функциональности с обратной совместимостью, PATCH — при исправлении багов. В Git Flow каждый finish release автоматически создаёт коммит в main с тегом версии.

Main ветка — единственная, которая развёртывается в продакшн. Для мобильных проектов это означает, что при push в main запускается пайплайн сборки App Bundle или IPA и публикации в Google Play / App Store. В настройках CI/CD GitLab main защищена от force-push и удаления.

Семантическое версионирование и теги

Каждый коммит в main сопровождается тегом в формате SemVer: vMAJOR.MINOR.PATCH. MAJOR — для несовместимых изменений API, MINOR — для новой функциональности с обратной совместимостью, PATCH — для исправления багов. Пример: v2.1.0 означает второй мажорный релиз с новыми фичами и без багфиксов. В Git Flow теги создаются автоматически при finish release или hotfix через команду git flow release finish.

Develop ветка: интеграционная линия разработки

Develop — вторая бессрочная ветка Git Flow, предназначенная для интеграции всех завершённых фич. Разработчики вливают feature-ветки в develop после прохождения код-ревью и CI/CD проверок. Develop содержит последнюю стабильную версию кода, включающую все реализованные фичи текущего спринта.

По данным DataSift Git Flow Guide, 2024, develop может быть временно нестабильной из-за незавершённых интеграций. Для предотвращения проблем команды практикуют Continuous Integration (CI): каждая фича перед слиянием в develop проходит полный набор тестов. Если CI упал — разработчик фиксает код до следующего слияния. Develop всегда привязана к актуальной версии main: сразу после релиза develop синхронизируется с main через слияние.

Feature-ветки: разработка новой функциональности

Feature-ветки — временные ветки для разработки отдельных фич, багфиксов или экспериментов. Каждая feature-ветка создаётся от develop и после завершения вливается обратно в develop. Имя feature-ветки обычно содержит номер задачи или краткое описание: feature/APP-123-add-oauth, feature/redesign-profile. В Git Flow feature-ветки могут существовать неограниченное время.

По данным Pro Git Book, 2024, feature-ветки — это изолированная среда разработки: изменения в одной ветке не влияют на другие до момента слияния. В мобильных проектах feature-ветки синхронизируются с develop через rebase или merge, чтобы избежать больших конфликтов при finish. Рекомендуется rebase feature-ветки на develop перед созданием MR.

# Ручное создание feature-ветки (без git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Создание MR в GitLab через CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release-ветки: подготовка релиза

Release-ветки — временные ветки, создаваемые от develop для подготовки релиза. Когда develop содержит достаточный набор фич для новой версии, команда создаёт ветку release/X.Y.Z (например, release/2.1.0). В этой ветке вносятся только финальные правки: бамп версии, обновление локализации, финальное тестирование, исправление критических багов.

По данным Atlassian Git Tutorials, 2024, release-ветка решает ключевую проблему: изоляция финальных правок от параллельной разработки. Пока release готовится к выходу, в develop продолжают вливаться новые фичи для следующего релиза. После завершения release-ветка вливается в main (с тегом) и в develop (чтобы синхронизировать бамп версии).

Hotfix-ветки: срочные исправления в продакшне

Hotfix-ветки — временные ветки для срочного исправления критических багов в продакшне. Единственный тип ветки Git Flow, который создаётся от main, а не от develop. Формат имени: hotfix/X.Y.Z+1 (например, hotfix/2.1.1). После завершения hotfix-ветка вливается одновременно в main (как новый патч-релиз) и в develop (чтобы фикс не потерялся при следующих релизах).

По данным DataSift Git Flow Guide, 2024, hotfix-ветки должны быть максимально короткими — только исправление и тест. Hotfix не должен включать новые фичи или рефакторинг. В мобильной разработке hotfix применяется для исправления критических падений (crash rate > 0.1%), уязвимостей безопасности или блокирующих багов в App Store.

Плюсы и минусы Git Flow для мобильной разработки

Git Flow даёт чёткую структуру, которая особенно полезна для крупных команд и проектов с регулярными релизами. Плюсы: изоляция незавершённых фич в feature-ветках, возможность подготовки релиза без блокировки разработки, поддержка нескольких версий через hotfix. Минусы: сложность для начинающих, необходимость регулярного rebase feature-веток, конфликты при долгоживущих ветках.

По данным Martin Fowler, 2024, главный недостаток Git Flow — долгоживущие feature-ветки. Если фича разрабатывается 2+ недели без синхронизации с develop, конфликт при слиянии становится значительным. Для мобильных проектов рекомендуется синхронизировать feature-ветку ежедневно через rebase на develop.

Git Flow не рекомендуется для проектов с Continuous Deployment (каждый коммит в main → в продакшн). Для таких проектов GitHub Flow или Trunk-Based Development дают более простую и быструю модель. Но для проектов с релизными циклами и поддержкой старых версий Git Flow остаётся оптимальным выбором.

Когда Git Flow вреден для команды

Git Flow становится проблемой в трёх случаях: команда менее 5 человек (избыточная сложность), Continuous Deployment (задержка поставки), отсутствие дисциплины rebase (долгоживущие feature-ветки создают merge-конфликты). Если команда тратит больше 20% времени на слияние веток и разрешение конфликтов — Git Flow не подходит данной команде даже при крупном размере.

Альтернативы Git Flow: GitHub Flow и Trunk-Based Development

Альтернативы Git Flow предлагают более простой процесс для команд, практикующих CI/CD. GitHub Flow использует только одну бессрочную ветку (main) и feature-ветки. Каждая фича создаётся от main, после ревью и CI вливается обратно в main и сразу развёртывается. GitHub Flow проще, но не поддерживает изоляцию незавершённых фич и параллельную подготовку релиза.

По данным GitHub Docs, 2024, Trunk-Based Development (TBD) идёт ещё дальше: все разработчики работают в одной ветке (trunk), используя короткоживущие feature-ветки на 1–2 дня. Feature toggles (флаги фич) управляют видимостью незавершённого кода. TBD требует высокой дисциплины CI/CD и автоматизации тестирования.

• GitHub Flow — одна main + feature-ветки, идеально подходит для CI/CD и небольших команд
• GitLab Flow — развивает Git Flow с environment-ветками (staging, production)
• Trunk-Based Development — одна ветка + feature toggles, максимум CI/CD, минимум слияний
• One Flow — упрощённый Git Flow без develop-ветки, только main + feature + release