Vincent Driessen published Git Flow in 2010, back when most teams shipped software as numbered versions. The model sorts work into five branch types, which are main, develop, feature, release and hotfix.
A team can prepare a release on its own branch while feature work carries on, and patch production without waiting for the next version.
Driessen added a reflection note on March 5, 2020, and it tells teams that deliver continuously to pick a simpler workflow. The original git-flow command-line extension was archived on October 14, 2025. Its repository now sends people to git-flow-next.
What Is Git Flow?
Every branch gets a fixed role under Git Flow, so feature work, releases and urgent production fixes each follow a set path. It’s a convention for using branches, not a program.
Driessen put it on nvie.com on January 5, 2010, in a post titled “A successful Git branching model”. He wrote it for version-based software, where each release carries a version number.
Parallel work is the problem it deals with. One group stabilizes the current release while another keeps building features for the next one, and the branch rules keep the two streams apart (Atlassian’s Gitflow tutorial describes this split).
Like most shared Git workflows, it only holds up when the whole team follows the same rules.
People mix up the model and the tool a lot. The model is just the set of branch rules in the 2010 post. The git-flow extension is a separate command-line add-on that automates those rules. GitKraken’s guide states that Git Flow is a branching strategy, so the model itself has nothing to download.
One naming difference trips people up. The 2010 post calls the production branch master, while Atlassian’s tutorial uses main for the same role.
The Five Branch Types in Git Flow
Main and develop are long-lived and never get deleted. Feature, release and hotfix branches are short-lived, and each one is deleted once it merges into a long-lived branch (Kodeco, Advanced Git).
| Branch | Branches from | Merges into | Name pattern |
|---|---|---|---|
| main | Repository default | Receives release and hotfix merges | main |
| develop | main, at setup | Receives feature merges | develop |
| feature | develop | develop | feature/\* |
| release | develop | main and develop | release/\* |
| hotfix | main | main and develop | hotfix/\* |
None of these is special to Git itself. Each is an ordinary Git branch used under strict rules about where it starts and where it ends up.
Main and develop
According to Driessen’s original post, every merge into main is a production release by definition.
That keeps main clean. Its latest commit always reflects code that’s ready to ship.
Develop works the other way around. It collects the latest finished work for the next release, and the automatic nightly builds run from it.
Feature, release and hotfix branches
A feature branch forks from develop and merges back into develop. It lives as long as the feature is in development, and it just gets discarded if the experiment fails.
Release branches fork from develop once develop holds everything planned for the version. They take bug fixes and release metadata, and no new features.
Hotfix is the odd one out. It’s the only branch that forks directly from main, and it patches a live production problem without waiting for the next release.
Naming prefixes
The original post and the extension disagree on separators.
In the post, feature branches can take any name except master, develop, release-\* and hotfix-\*, while releases and hotfixes use a hyphen, as in release-1.2. The extension’s init command offers feature/, release/, hotfix/ and support/ as prefixes, with an empty version tag prefix by default (Atlassian).
So release-1.2 in the post becomes release/1.2 in a repository set up with the extension. Pick one convention per repository and keep it.
How Does Work Move From Feature to Release to Hotfix?
Features merge into develop. A release branch forks from develop and merges into main and develop, and a hotfix forks from main and merges into both. In Driessen’s version every one of those merges uses --no-ff, so each branch stays visible in history.
Merging a feature into develop
The --no-ff flag forces a merge commit even when a fast-forward is possible.
That keeps the feature branch visible in history and groups its commits together. With the merge commit, reverting a whole feature is simple. Without it, the history is a flat line of commits and reverting the group is painful (Driessen).
Watch the manual route. Atlassian’s plain-git examples run git merge without the flag, so a feature that could fast-forward loses its grouping.
Finishing a release branch
A release branch forks from develop once develop holds every feature planned for that release. The version number gets assigned at that moment, not earlier.
- Branch release-1.2 off develop after all target features are merged.
- Bump the version number in the files that carry it, and commit.
- Accept bug fixes and release metadata only. New features wait for the next release.
- Merge the release branch into main with –no-ff.
- Tag the merge commit on main.
- Merge the release branch back into develop, and resolve the conflict the version bump often causes.
- Delete the release branch.
The Git tag on main is what lets a hotfix find the exact production version later. Driessen adds that the -s or -u flags sign the tag cryptographically.
Skip the back-merge and the next release ships without the fixes made on the release branch.
Patching production with a hotfix
Hotfix branches are the only branches that fork directly from main.
They fix a live bug while the team keeps working on develop, so the fix doesn’t wait for the next release.
The version number moves one patch step. If 1.2 is live, the hotfix is 1.2.1, which follows the major.minor.patch pattern that semantic versioning describes.
After the fix, merge into main, tag the merge, then merge into develop.
There’s one exception. When a release branch is open, the hotfix merges into that release branch instead of develop, and reaches develop when the release finishes. Atlassian’s tutorial describes the same rule.
Git Flow Commands and What They Do
The git-flow extension adds a subcommand for each branch type. You run git flow init once per repository, then start and finish for every feature, release and hotfix. Each finish command runs the merge and cleanup steps from the previous section.
git flow initasks for the production branch name (Atlassian’s walkthrough shows main as the default, while the 2010 post calls it master), the develop branch name and the branch prefixes, then creates develop on an existing repository. Adding -d accepts every default.git flow feature start my-featurecreates feature/my-feature from develop and switches to it.git flow feature finish my-featuremerges the branch into develop with –no-ff and deletes it.git flow feature publishpushes the branch to the remote so teammates can work on it.
Releases and hotfixes follow the same start and finish pattern.
- git flow release start 1.2 creates release/1.2 from develop
- git flow release finish 1.2 merges into main and develop, tags the release and deletes the branch
- git flow hotfix start fix-login creates hotfix/fix-login from main
- git flow hotfix finish fix-login merges into main and develop, the same way a release does
- git flow support start creates a branch for maintaining an older release. The original extension and the AVH edition both include it, but the 2010 post doesn’t describe support branches
Every command has a plain-git equivalent. Atlassian’s tutorial lists both side by side, and a Git cheat sheet covers the underlying commands.
That makes the extension optional. A team that follows the branch rules by hand ends up with the same repository.
Which Git Flow Tool Is Still Maintained?
As of October 2026, git-flow-next is the actively maintained implementation, and the one the original repository points users to. The git-flow extension and the AVH edition are both archived and read-only on GitHub.
| Tool | Status | Maintainer |
|---|---|---|
| git-flow extension (original) | Archived October 14, 2025 | Vincent Driessen |
| AVH edition | Archived June 19, 2023 | Peter van der Does |
| git-flow-next | Active, 2.1.0 released September 8, 2026 | Tower |
The archived original repository now points users to git-flow-next, a backward-compatible reimplementation in Go built by the team behind the Tower Git client.
A maintained fork’s README dates the last commit to the AVH edition at May 23, 2019, four years before its archive. Older install guides, including the AVH edition’s own macOS page, still recommend it.
GUI clients bundle their own copy. Sourcetree’s release notes show a switch to the AVH edition in version 2.7.4 (June 5, 2018), so check which implementation your client embeds.
Installing git-flow-next takes one command on most systems.
- macOS and Linux: brew install git-flow-next
- Windows: winget install GitTower.GitFlowNext, or scoop install git-flow-next
- Manual install: put the release binary on your PATH under the name git-flow
Windows has a trap here. The binary must be named exactly git-flow.exe, and hidden file extensions can turn it into git-flow.exe.exe, which Git doesn’t recognize as a subcommand. Since version 2.0.0, release archives contain the binary already named git-flow, so no renaming is needed after extraction.
Version 2.0.0 (August 9, 2026) also changed the git flow version output to match what AVH-era tooling expects. Scripts that matched the earlier git-flow-next string need an update.
Beyond the classic commands, git-flow-next adds a few things.
- Configurable branch names, prefixes and parent relationships
- Merge, rebase or squash as the strategy when finishing a branch
- Hooks and filters around start and finish
- A committable .gitflow file that carries a team’s branch model (added in 2.0.0)
Setting the finish strategy to rebase rewrites the topic branch on top of its parent, so history reads as a straight line instead of grouped merges.
Its documentation also carries workflow guides for Gitflow, GitHub Flow, GitLab Flow and custom setups.
For a new project, I’d go with git-flow-next or plain git commands. Starting on an archived extension means nobody will fix its bugs.
When Git Flow Does Not Fit
Git Flow suits software that ships numbered versions or supports several versions at once. It fits poorly when a single version of a web app is deployed continuously.
Driessen drew that line himself on March 5, 2020, in a note added to the top of the original post. He wrote that web apps are usually delivered continuously, rarely rolled back and rarely run in several versions at once, so teams in that position should pick a simpler workflow such as GitHub flow.
Atlassian’s tutorial now labels Gitflow a legacy workflow that lost ground to trunk-based workflows and can be hard to run with CI/CD. Its body text still says the workflow suits continuous delivery, so the header and the body contradict each other.
I’d weigh the author’s note over the tutorial body. He wrote the model and he set its boundary.
DORA’s analysis of 2016 and 2017 data links stronger delivery performance to 3 or fewer active branches and merges to trunk at least once a day, with no code freezes.
DORA treats trunk-based development as a required practice for continuous integration. Git Flow spends 2 of those 3 branches on main and develop, and one open feature plus one release branch puts a repository at 4.
The release branch also works as a scoped freeze, because no new features enter it after it forks (Atlassian).
Where the model fits, it works well. A fixed software release cycle gives the release branch a natural moment to fork.
Teams that ship numbered versions on a schedule get the most out of it. So do products with several supported versions in the wild (Driessen), and releases that need a stabilization phase while feature work continues. It also gives production hotfixes a dedicated, documented path (Atlassian).
The costs are real too. Long-lived branches drift from the trunk and produce conflicting updates (Atlassian). Commits get larger, merges get bigger than they’d be in trunk-based work, and CI/CD pipelines rub against the model.
If customers install numbered versions, or you maintain more than one at a time, keep Git Flow. If you deploy a single version of a web app on every merge, drop the develop branch and use something simpler.
Git Flow vs GitHub Flow, GitLab Flow and Trunk-Based Development
The alternatives all run with fewer long-lived branches than Git Flow. They differ in how code reaches production and how many versions they support.
| Workflow | Long-lived branches | Release model | Best fit |
|---|---|---|---|
| Git Flow | main, develop | Release branches, tagged versions | Versioned software, several versions supported |
| GitHub flow | Default branch only | Merge after pull request review | Teams that deploy regularly |
| GitLab flow | main plus production, environment or stable branches | Merge downstream, fix upstream first | Staged environments or release versions |
| Trunk-based development | Trunk only | Release from trunk or just-in-time release branches | Continuous integration and delivery teams |
GitHub flow is a lightweight, branch-based workflow. You branch from the default branch, open a pull request, merge after review and delete the branch (GitHub Docs). GitLab’s documentation notes that it assumes you can deploy to production on every merge, which is continuous deployment in practice.
GitLab’s documentation names Git flow’s first problem, which is that developers must work on develop instead of main. GitLab flow keeps feature branches merging into main, then adds a production branch, environment branches such as staging and pre-production, or stable release branches.
Its bug fix rule also differs from Git Flow’s hotfix path. GitLab flow fixes the bug in main first and cherry-picks it into the release branch, a policy it calls upstream first.
Trunk-based development goes furthest. DORA describes branches that typically last no more than a few hours, and trunkbaseddevelopment.com says release branches are cut just in time or skipped when the team releases from trunk.
Numbered versions with several supported at once point to Git Flow, or to GitLab flow with stable release branches. One version deployed on every merge fits GitHub flow. If that one version passes through staged environments before production, GitLab flow with environment branches is the better match. Teams that integrate daily and have fast automated tests behind them can go trunk-based.
Branch count follows release shape, so settle the shape first.
Git Flow FAQ
Can Git Flow be used with pull requests?
Yes. Feature branches merge into develop through pull requests like in any other workflow, and Atlassian names the release-to-main merge as another natural review point.
The finish command merges locally, so a team that reviews on the hosting platform merges there instead.
Is Git Flow suitable for small teams?
Team size doesn’t decide it. Release shape does.
A two-person team shipping numbered versions can use Git Flow, while a ten-person team deploying one web app continuously gains little from it. That matches the criteria in Driessen’s 2020 note.
Does git flow init change an existing repository?
Only the setup, not the history. It creates develop when missing and stores the main branch name and branch prefixes in the repository’s git config.
Stopping just means no longer running git flow commands. Every branch it created is an ordinary Git branch.
What does the support subcommand do?
It creates a long-term maintenance branch for an older release, from a base commit or tag you name. The 2010 post doesn’t cover customers who stay on old releases and still need bug fixes, so this is an addition of the extension. Both the original extension and the AVH edition include it.
git-flow-next also supports support branches.
Moving a Team Off Git Flow Safely
A team leaves Git Flow safely by closing branches in a fixed order, not by deleting develop on day one. Each step removes one source of unmerged work before the next begins.
Finish every open release and hotfix branch first. Then merge develop into main and retire develop. After that, shorten feature branches until each one merges within a day.
Open release and hotfix branches carry changes that sit in only one of main and develop until their back-merge lands. After the final merge, deleting the develop branch in Git, locally and on the remote, leaves a repository shaped like GitHub flow.
You do give something up. The stabilization phase goes away, and so does parallel upkeep of several released versions.
This advice holds as of October 2026. A requirement to support more than one released version at once would reverse it, and the release branches would stay.
- MongoDB Cheat Sheet - October 20, 2026
- Adding AI Video Generation to a Software Product: Architecture, Cost Guardrails and QA - October 20, 2026
- Show Hidden Characters, Spaces, and Line Endings in Notepad++ - October 19, 2026
