GitFlow Branching Model

A branching strategy proposed by Vincent Driessen in 2010 for projects with scheduled, versioned releases. Two long-lived branches — main and develop — anchor the history, while feature, release, and hotfix branches handle everything in between.

Ad 728×90

main & develop — the long-lived branches

Why: main always reflects production-ready code (every commit on it is a release), while develop is the integration branch where finished features pile up before the next release.

Create develop once, branching off main

git switch -c develop main

git push -u origin develop

Day to day, all work merges into develop — main only moves forward via release/ and hotfix/ branches

feature/* — building something new

Why: every feature gets its own branch off develop, so half-finished work never blocks a release.

git switch -c feature/login-form develop

...commit your work...

git switch develop

git merge --no-ff feature/login-form

git branch -d feature/login-form

git push origin develop

release/* — preparing a release

Why: once develop has everything for the next version, a release branch freezes scope — only bug fixes, docs, and version bumps happen here while feature work continues on develop.

git switch -c release/1.2.0 develop

...bump version numbers, fix release-only bugs...

Ship it: merge into main and tag

git switch main

git merge --no-ff release/1.2.0

git tag -a v1.2.0 -m "Release 1.2.0"

Bring the release-branch fixes back into develop too

git switch develop

git merge --no-ff release/1.2.0

git branch -d release/1.2.0

git push origin main develop --tags

hotfix/* — fixing production now

Why: a hotfix branches straight off main so an urgent fix can ship without waiting for develop's in-progress work, then merges into both main and develop so the fix isn't lost on the next release.

git switch -c hotfix/1.2.1 main

...fix the bug...

git switch main

git merge --no-ff hotfix/1.2.1

git tag -a v1.2.1 -m "Hotfix 1.2.1"

git switch develop

git merge --no-ff hotfix/1.2.1

git branch -d hotfix/1.2.1

git push origin main develop --tags

Is GitFlow right for your project?

Note: GitFlow's overhead pays off for software with scheduled, versioned releases (desktop apps, libraries, anything that supports multiple versions in production). For continuously deployed web apps, a simpler trunk-based flow is usually a better fit.

GitFlow — versioned releases, multiple supported versions main + develop, with feature/, release/, and hotfix/ branches

GitHub Flow / trunk-based — continuous deployment main is always deployable short-lived feature branches merge straight into main risky changes ship behind feature flags instead of long-lived branches