Gitflow
In short
Gitflow is a Git branching model that uses long-lived main and develop branches plus feature, release, and hotfix branches to manage scheduled releases.
What is Gitflow?
Gitflow is a branching strategy that Vincent Driessen described in 2010 in a blog post titled 'A successful Git branching model'. It gives each kind of work its own type of branch, with strict rules about where the branch starts and where it merges back. The model was designed for software shipped as numbered versions on a schedule, such as desktop apps, mobile apps, and libraries.
Two branches live forever: main (originally master) holds only released code, with each release marked by a tag, and develop collects finished features for the next release. Feature branches start from develop and merge back into it; when enough features are ready, a release branch is cut from develop for final testing and version bumps, then merged into both main and develop. Urgent production fixes go on hotfix branches made from main, which are also merged into both.
Gitflow works like a publishing house: writers draft chapters separately in feature branches, an editor assembles the next edition in develop, a proofreading stage freezes it before printing in a release branch, and errata sheets fix printed copies right away as hotfixes. Optional command-line extensions offer shortcuts such as git flow feature start, but the model itself is just a naming and merging convention built on ordinary Git commands.
Gitflow is most often compared with trunk-based development, where everyone merges small changes into a single main branch at least daily. Gitflow's long-lived branches and batched releases add merge work and delay feedback, which fits poorly with continuous delivery, and in 2020 its author added a note recommending simpler workflows for web apps that are deployed continuously. It remains a reasonable fit for products that must support several released versions at once.
Key takeaways
- Gitflow uses two permanent branches:
mainfor released code anddevelopfor upcoming work. - Feature branches come from
develop, release branches prepare a version, and hotfix branches patch production. - Release and hotfix branches merge into both
mainanddevelop, and each release is tagged. - It suits versioned, scheduled releases better than continuous deployment.
- Trunk-based development is the main lighter-weight alternative.
Example
# Start a feature from develop and merge it back when done
git switch -c feature/cart develop
git switch develop && git merge --no-ff feature/cart
# Cut a release branch, then merge it into main and back into develop
git switch -c release/1.4.0 develop
git switch main && git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop && git merge --no-ff release/1.4.0
# Fix production with a hotfix branch made from main
git switch -c hotfix/1.4.1 main
git switch main && git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Hotfix 1.4.1"
git switch develop && git merge --no-ff hotfix/1.4.1Readers ask
What is the difference between Gitflow and trunk-based development?
Gitflow keeps long-lived main and develop branches and moves work through feature, release, and hotfix branches in batches. Trunk-based development has one main branch that everyone merges small changes into continuously, which suits teams that deploy often.
Is Gitflow still used?
Yes, especially for products with versioned releases, such as mobile apps, installed software, and libraries that maintain older versions. Many web teams that deploy continuously have moved to simpler workflows with a single main branch and short-lived feature branches.
What is the develop branch in Gitflow?
develop is the integration branch where completed features are merged while they wait for the next release. main only receives code through release and hotfix branches, so it always reflects what is in production.
See also
- Trunk-Based DevelopmentVersion Control, p. 38Trunk-based development is a branching strategy where developers merge small changes into one shared main branch at least daily, keeping it always releasable.
- BranchVersion Control, p. 2A branch in Git is an independent line of development that lets you work on a feature or fix in isolation, without affecting the main code until you merge it.
- MergeVersion Control, p. 29A merge in Git combines the changes from one branch into another, joining separate lines of development back together into a single, shared history.
- Git TagVersion Control, p. 23A Git tag is a named, permanent pointer to a specific commit, most often used to mark release versions such as v1.0.0 in a repository's history.
- Semantic VersioningVersion Control, p. 35Semantic versioning is a MAJOR.MINOR.PATCH numbering scheme in which each part signals whether a release breaks compatibility, adds features, or fixes bugs.
- Pull RequestVersion Control, p. 32A pull request is a proposal to merge changes from one branch into another, giving teammates a place to review, discuss, and test the code before it is merged.
- HotfixVersion Control, p. 28A hotfix is an urgent fix for a serious problem in production, such as a crash or security hole, released quickly and outside the normal release schedule.
Spotted a mistake or something missing on this page?Suggest an edit