Gitflow: What is the Gitflow Workflow?

What is Gitflow?

Gitflow is a Git branching model designed by Vincent Driessen in 2010 that defines a strict set of rules for organizing branches in a software project. It structures the development workflow around two permanent branches (main and develop) and several types of temporary branches (feature, release, hotfix). This model was one of the first to formalize a complete Git workflow and remains widely used in the industry.

The central idea of Gitflow is to clearly separate stable code (ready for production) from code under development. The main branch always reflects the production state, while develop is the integration branch where all in-progress features converge. This separation brings essential structure and predictability, especially for teams working on projects with defined release cycles.

At Kern-IT, we adapt Gitflow principles to our projects based on their size and complexity. For projects requiring planned releases and multi-version support, Gitflow provides invaluable structure. For simpler projects with continuous deployment, we opt for a streamlined GitHub Flow.

Why Gitflow Matters

Gitflow solves a problem every development team faces: how to organize parallel work while maintaining stable production code.

• Clear structure: each branch type has a defined role. Developers know exactly where to create their branches and where to merge them.
• Production stability: the main branch only receives tested, validated code, minimizing the risk of production regressions.
• Release management: release branches allow preparing, testing, and stabilizing a version without blocking development of the next features.
• Isolated hotfixes: urgent production fixes follow a dedicated path that ensures they are applied quickly while being reintegrated into the development flow.
• Parallel work: multiple feature branches can coexist, each developed and tested independently before integration.

How It Works

The Gitflow workflow revolves around five branch types. The main and develop branches are permanent. main contains the production code, with each commit tagged with a version number. develop is the integration branch that accumulates features for the next release.

feature/* branches are created from develop and merged back into develop once the feature is complete. Each feature has its own branch, enabling isolated development and focused pull requests.

release/* branches are created from develop when all planned features for a version are ready. On this branch, only bug fixes and minor adjustments are allowed. Once the release is stabilized, it is merged into main (with a version tag) and into develop (to pick up the fixes).

hotfix/* branches are created directly from main to fix a critical production bug. Once the fix is validated, it is merged into main (with an incremented version tag) and into develop to preserve the fix in future releases.

Gitflow vs GitHub Flow

GitHub Flow is a simplified alternative to Gitflow with only one permanent branch (main). Developers create branches directly from main, open pull requests, and merge into main after review. Code is deployed immediately after the merge.

GitHub Flow is better suited for projects with continuous deployment, where each merge can go to production. Gitflow is more appropriate for projects with planned release cycles, parallel versions to maintain, or lengthy validation processes.

Concrete Example

A Kern-IT project with monthly releases uses Gitflow. Three developers work in parallel on feature branches: feature/user-export, feature/invoice-reminder, and feature/dashboard-charts. Each feature is merged into develop after review.

Mid-month, a release/2.3.0 branch is created from develop. The QA team tests this release and reports two bugs, fixed directly on the release branch. Meanwhile, developers continue working on new features in develop. The release is validated, merged into main (tagged v2.3.0) and into develop.

A week later, a critical bug is discovered in production. A hotfix/payment-timeout is created from main, fixed and tested quickly, then merged into main (tagged v2.3.1) and into develop.

Best Practices

1. Adapt the model to your context: Gitflow is not a universal recipe. Simplify it if your project does not need the full complexity (no release branches if you practice continuous deployment).
2. Automate back-merges: merges from release and hotfix into develop are often forgotten. Automate them or create checklists.
3. Use semantic tags: follow semantic versioning (semver) for your release tags: MAJOR.MINOR.PATCH.
4. Document your workflow: formalize branching conventions in a document accessible to the entire team to avoid practice divergences.

Conclusion

Gitflow is a proven branching model that brings structure and predictability to the development process. While it may seem complex at first, its logic is sound and its benefits are tangible for teams working on projects with structured release cycles. The key is to understand the underlying principles and adapt them to the reality of your project and team.