Git Flow: що це таке, модель гілок та використання в проектах

What Is Git Flow?

Git Flow is a Git branching model that defines a strict structure of branches and merge rules for managing development, releases, and fixes. Vincent Driessen published the article “A successful Git branching model” in January 2010, and since then Git Flow has become the de facto standard in enterprise Java and .NET development. The main idea is to split the code into five branch types with different stability levels.

According to Atlassian Git Tutorials, 2024, Git Flow is based on two perpetual branches: main (formerly master) and develop. All other branches are temporary: feature, release, hotfix. Each branch type has a clearly defined lifecycle and merge rules. In mobile development, Git Flow is used in projects with regular release cycles (2–4 weeks) and support for multiple versions.

Git Flow differs from simple models (GitHub Flow) by requiring a separate develop branch for integration. This adds one step to the merge process but provides additional isolation of unfinished features from release-ready code.

Vincent Driessen and the History of Git Flow

In 2010, Vincent Driessen published the post “A successful Git branching model,” which became one of the most cited in Git history. The model was created for a project with fixed releases and parallel version support. In 2020, Driessen acknowledged that Git Flow is outdated for modern CI/CD practices, but the model remains relevant for projects with long release cycles and the need to support older versions.

# Ініціалізація 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 Branch: Release Code and Tagging

Main (formerly master) is the primary branch containing only release code ready for deployment. Each commit in main should correspond to a specific product version, tagged with semantic versioning format, e.g., v1.0.0, v1.1.0. No direct development is done in main — changes arrive here only through release or hotfix branches.

According to semver.org, 2024, tags in main use the MAJOR.MINOR.PATCH format. MAJOR is incremented for incompatible API changes, MINOR for backward-compatible functionality additions, PATCH for bug fixes. In Git Flow, each finish release automatically creates a commit in main with a version tag.

The Main branch is the only one deployed to production. For mobile projects, this means that a push to main triggers the App Bundle or IPA build pipeline and publication to Google Play / App Store. In GitLab CI/CD settings, main is protected from force-push and deletion.

Semantic Versioning and Tags

Each commit in main is accompanied by a tag in SemVer format: vMAJOR.MINOR.PATCH. MAJOR — for incompatible API changes, MINOR — for new backward-compatible functionality, PATCH — for bug fixes. Example: v2.1.0 means the second major release with new features and no bug fixes. In Git Flow, tags are created automatically when finishing a release or hotfix via the git flow release finish command.

Develop Branch: Integration Line of Development

Develop is the second perpetual branch in Git Flow, designed for integrating all completed features. Developers merge feature branches into develop after passing code review and CI/CD checks. Develop contains the latest stable version of the code, including all implemented features of the current sprint.

According to DataSift Git Flow Guide, 2024, develop can be temporarily unstable due to ongoing integrations. To prevent issues, teams practice Continuous Integration (CI): each feature must pass a full test suite before merging into develop. If CI fails, the developer fixes the code before the next merge. Develop is always tied to the current version of main: immediately after a release, develop is synchronized with main through a merge.

Feature Branches: Developing New Functionality

Feature branches are temporary branches for developing individual features, bug fixes, or experiments. Each feature branch is created from develop and merged back into develop upon completion. The feature branch name usually contains the task number or a brief description: feature/APP-123-add-oauth, feature/redesign-profile. In Git Flow, feature branches can exist indefinitely.

According to Pro Git Book, 2024, feature branches are an isolated development environment: changes in one branch do not affect others until merging. In mobile projects, feature branches are synchronized with develop via rebase or merge to avoid large conflicts at finish. It is recommended to rebase the feature branch onto develop before creating an 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 Branches: Preparing a Release

Release branches are temporary branches created from develop to prepare a release. When develop contains enough features for a new version, the team creates a release/X.Y.Z branch (e.g., release/2.1.0). Only final changes are made in this branch: version bump, localization updates, final testing, critical bug fixes.

According to Atlassian Git Tutorials, 2024, the release branch solves a key problem: isolating final changes from parallel development. While the release is being prepared, new features for the next release continue to be merged into develop. After completion, the release branch is merged into main (with a tag) and into develop (to synchronize the version bump).

Hotfix Branches: Urgent Production Fixes

Hotfix branches are temporary branches for urgently fixing critical bugs in production. The only Git Flow branch type created from main instead of develop. Name format: hotfix/X.Y.Z+1 (e.g., hotfix/2.1.1). After completion, the hotfix branch is merged simultaneously into main (as a new patch release) and into develop (so the fix is not lost in future releases).

According to DataSift Git Flow Guide, 2024, hotfix branches should be as short as possible — only the fix and testing. A hotfix should not include new features or refactoring. In mobile development, hotfixes are used for critical crashes (crash rate > 0.1%), security vulnerabilities, or blocking bugs in the App Store.

Pros and Cons of Git Flow for Mobile Development

Git Flow provides a clear structure that is especially useful for large teams and projects with regular releases. Pros: isolation of unfinished features in feature branches, ability to prepare a release without blocking development, support for multiple versions via hotfixes. Cons: complexity for beginners, need for regular feature branch rebase, conflicts with long-lived branches.

According to Martin Fowler, 2024, the main drawback of Git Flow is long-lived feature branches. If a feature is developed for 2+ weeks without synchronization with develop, the merge conflict becomes significant. For mobile projects, it is recommended to synchronize the feature branch daily via rebase onto develop.

Git Flow is not recommended for projects with Continuous Deployment (every commit in main → production). For such projects, GitHub Flow or Trunk-Based Development provide a simpler and faster model. But for projects with release cycles and support for older versions, Git Flow remains the optimal choice.

When Git Flow Is Harmful for the Team

Git Flow becomes a problem in three cases: teams smaller than 5 people (unnecessary complexity), Continuous Deployment (delayed delivery), lack of rebase discipline (long-lived feature branches create merge conflicts). If a team spends more than 20% of its time on merging branches and resolving conflicts — Git Flow is not suitable for that team even if it is large.

Alternatives to Git Flow: GitHub Flow and Trunk-Based Development

Alternatives to Git Flow offer a simpler process for teams practicing CI/CD. GitHub Flow uses only one perpetual branch (main) and feature branches. Each feature is created from main, after review and CI it is merged back into main and immediately deployed. GitHub Flow is simpler but does not support isolation of unfinished features or parallel release preparation.

According to GitHub Docs, 2024, Trunk-Based Development (TBD) goes even further: all developers work in a single branch (trunk), using short-lived feature branches of 1–2 days. Feature toggles control the visibility of unfinished code. TBD requires high CI/CD discipline and test automation.

• GitHub Flow — one main + feature branches, ideal for CI/CD and small teams
• GitLab Flow — extends Git Flow with environment branches (staging, production)
• Trunk-Based Development — one branch + feature toggles, maximum CI/CD, minimum merges
• One Flow — simplified Git Flow without a develop branch, only main + feature + release