W3docs
en
Log in

Gitflow workflow

Learn the Gitflow workflow — main, develop, feature, release, and hotfix branches — and when its structure helps a versioned product.

Overview

Gitflow is a structured branching model, popularized by Vincent Driessen in 2010, designed for projects with scheduled, versioned releases. Instead of a single integration branch, it uses two long-lived branches plus three kinds of supporting branches, each with a defined purpose. The structure makes release management explicit at the cost of more ceremony.

Gitflow branches: main, develop, feature, release, and hotfix lanes

The two long-lived branches

  • main holds production-ready code. Every commit on main corresponds to a released version and is usually tagged.
  • develop is the integration branch where completed features accumulate between releases. It always contains the latest delivered changes for the next release.

The three supporting branches

Feature branches branch off develop and merge back into develop. They hold work for upcoming functionality and never interact with main directly.

git switch develop
git switch -c feature/search
# ...work and commit...
git switch develop
git merge feature/search

Release branches branch off develop when it is feature-complete for a release. They exist for final polish — version bumps, last bug fixes, release notes. When ready, a release branch merges into both main (and gets tagged) and back into develop so the fixes are not lost.

git switch -c release/1.4.0 develop
# ...stabilize...
git switch main
git merge release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop
git merge release/1.4.0

Hotfix branches branch off main to patch a production bug urgently. Like release branches, they merge into both main and develop.

When to use Gitflow

Gitflow shines when you ship distinct, versioned releases — desktop apps, libraries, or anything with maintained version numbers and the occasional emergency patch. The explicit release and hotfix branches give you a clear place to stabilize and to fix production without disturbing ongoing development.

The trade-offs

That structure is also Gitflow's weakness. The many branch types add overhead, and the long-lived develop branch can drift far from main, making merges painful. Teams practicing continuous delivery — shipping many times a day — usually find Gitflow too heavy and prefer the feature branch or trunk-based approach. Choose Gitflow when release cadence, not raw speed, is your priority.

Practice

Practice

Which statements about Gitflow are correct?