GitFlow

main, develop, feature, release and hotfix. Designed for versioned software with planned releases.

Context

Published by Vincent Driessen in 2010 for software with numbered versions and release cycles: desktop apps, mobile, libraries, on-premise products. Its own author later clarified that it is not ideal for web apps with continuous delivery.

Solution

Two permanent branches and three kinds of supporting branches:

Branch	Created from	Merges into	Purpose
`main`	—	—	Released code only, every commit is a tagged release
`develop`	`main`	—	Integration of what goes into the next release
`feature/*`	`develop`	`develop`	One feature
`release/*`	`develop`	`main` and `develop`	Stabilize and version a release
`hotfix/*`	`main`	`main` and `develop`	Urgent production fix

CSHARP

main     ──●─────────────────●───────────●──▶  (tags v1.0, v1.1, v1.1.1)
            \               / \         /
release      \       ●──●──●   \       /
              \     /           \     /
develop  ──●───●──●──●────●──●───●──●──●──▶
              \  /      \  /
feature        ●●        ●●
hotfix                      ●──────────●   (from main)

#Real costs

Two long-lived branches (main and develop) to keep in sync.
Large merges and conflicts when closing a release.
Bugs are found late: code takes long to reach main and production.
With continuous deployment the model gets in the way: develop and main are almost the same.

When NOT to use it

Web/SaaS apps that deploy several times a day.
Small teams without parallel supported versions: overhead with no return.
If you want Trunk-Based or real continuous integration: GitFlow works against it.

Tradeoffs

Pro	Con
Clear, explicit branch roles	Lots of ceremony and long-lived branches
Supports several versions and orderly hotfixes	Hard merges, late integration
Fits planned releases and staged QA	Slows down continuous delivery

#git #branching #gitflow #release