Jun 7, 2026·14 min read· gitflow· workflows· release-branches· versioning· team

Gitflow in 2026: still useful, or time to move on?

Gitflow has a bad reputation online, but it still earns its weight for versioned SDKs, regulated industries, and long support windows. Here is when it is right, and when it is wrong.

If you search "Gitflow" on the internet today, half the results will tell you it is dead. The other half will quote Vincent Driessen's 2010 post about it, often without mentioning the 2020 note he added on top.

The truth is in the middle. Gitflow is no longer the right default for most teams. But it is still the right choice for some — and the loud "Gitflow is dead" content has been bad for teams who genuinely need it. They end up adopting trunk-based development, hurting themselves, and concluding that Git is broken.

This post explains what Gitflow actually is, when it still earns its weight, and when it is the wrong fit. The goal is to give you a clear, honest read on a workflow that has been mis-described in both directions.

What Gitflow actually is

Vincent Driessen wrote "A successful Git branching model" in January 2010. It described a way to organise branches for software with versioned releases. The post became one of the most-cited Git articles ever written.

The model has five kinds of branches:

main — what is in production. Every commit on main is a released version.
develop — where new work integrates. The "next release in progress."
feature/* — short-lived branches for individual features, branched from and merged back into develop.
release/* — branches cut from develop when a release is being prepared. Only bug fixes go on a release branch. When the release ships, the branch merges into both main (with a tag) and develop.
hotfix/* — emergency fix branches cut directly from main. When fixed, merge back into both main (tagged) and develop.

The whole flow is built around one assumption: you ship discrete, named versions (v1.5, v1.6, v2.0), and you sometimes need to patch old versions without forcing customers to upgrade.

The 2020 note in context

In March 2020, Driessen added a note to the top of his own 2010 post. It is worth quoting in full:

"This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.

During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team."

Two things to notice. First, Driessen did not retract or deprecate the model — he scoped it. He told web-app teams to use something simpler. He did not tell SDK teams or embedded-software teams to abandon Gitflow. Second, he explicitly named the kind of software Gitflow was designed for: software where you support multiple versions in the wild and where rollback is not a clean option.

If your software looks like that, Gitflow is still the model he wrote about. The 2020 note is not "Gitflow is dead." It is "stop applying Gitflow where it does not fit."

When Gitflow still earns its weight

Three settings where Gitflow is genuinely the right tool.

Versioned SDKs and libraries

You ship a library — an iOS SDK, a Python package, a JavaScript framework. Thousands of downstream apps depend on it. You release v3.0, then v3.1, then v3.2. A security bug is found in v3.0. Half your users are on v3.0 because their host apps have not upgraded yet.

You need to ship v3.0.1 with only the security fix, without forcing every user to take v3.2. That means keeping a release/3.0 branch alive for as long as you support v3.0 — sometimes a year, sometimes more. Hotfixes cherry-pick or backport into that branch. The structure Driessen described is exactly what you need.

Regulated industries

Medical devices, aerospace, financial trading, parts of healthcare and government — these industries often require formal change-control records, scheduled releases, and frozen builds for QA. A release branch that sits stable for two weeks while QA runs end-to-end tests is not "branch overhead." It is the artifact the auditor needs to see.

Trunk-based development can work in these environments, but you usually end up rebuilding most of Gitflow's structure on top of TBD with custom tooling. Often the original model is simpler.

Long support windows for installed software

Desktop apps, on-premise enterprise software, embedded firmware. You cannot force the customer to upgrade. You ship a version, and that version may live on customer machines for two years. If they hit a bug, you ship a patch on that version. You need parallel timelines that live for years.

This is the original scope of Gitflow. It still fits.

Side by side: Gitflow vs GitHub Flow vs GitLab Flow

A comparison table. Skim what your team is, find your row.

Aspect	Gitflow	GitHub Flow	GitLab Flow
Long-lived branches	`main`, `develop`	`main` only	`main`, `pre-production`, `production`
Where features start	From `develop`	From `main`	From `main`
Where releases come from	`release/*` branch off `develop`	`main` directly	`production` branch
Hotfix mechanism	`hotfix/*` from `main`, merge to both	Branch from `main`, fix, ship	Cherry-pick to `production`
Supports old versions easily	Yes — release branches persist	No	No
Cognitive load	High	Low	Medium
Best fit	Versioned, multi-version-supported sw	Continuously deployed web	Web with staged environments

Notice the trade-off. Gitflow's cost is cognitive load — engineers must remember which branch to start from and where each kind of work merges back to. Its benefit is multi-version support. If you do not need multi-version support, you pay the cost for no return. If you do, you cannot easily get that capability anywhere else.

The real cost of Gitflow

Honest assessment. Gitflow's costs are not imaginary.

Mental model load. A new engineer joining a Gitflow team must learn five branch types and the rules about which merges where. That takes a few weeks to internalise. On a TBD team, the model fits on a sticky note.

Branch overhead. Every release requires creating a release/* branch, running QA, merging back to both main and develop, tagging, and deleting the release branch. The merges can conflict if develop has moved on. The first time it happens, it eats a day.

Merge complexity. Hotfixes that merge into both main and develop are easy to get wrong. The classic failure mode — a hotfix that ships to main but never gets to develop, then quietly disappears when the next release happens — is real, and it is what post #7 in this series (Release branches and hotfix workflows that don't lose commits) is about.

Atlassian's tutorial is misleading. Atlassian's Gitflow tutorial is widely linked, but it presents Gitflow as a general-purpose workflow without strongly flagging when it is appropriate. Many teams adopted it because Atlassian made it look universal. It is not.

If you are not in one of the three "earns its weight" scenarios above, these costs are paying for nothing.

When to migrate away

A short checklist. If most of these are true, your team is probably mis-applying Gitflow:

You deploy more than once a week.
You do not support old versions of your software — every customer is on the latest.
You have automated tests you trust.
You are not in a regulated industry that requires formal change records.
You have, or could have, feature flag infrastructure.
Your team complains about "merge overhead" or "release overhead" regularly.

If five or more of these apply, migration to a simpler workflow is likely worth the cost. Post #8 in this series, Migrating from Gitflow to trunk-based development, is the playbook.

If two or fewer apply, Gitflow is probably the right tool. Stay.

Three failure modes when Gitflow is mis-applied

To make the cost concrete, three patterns where Gitflow is wrong for a team and the symptoms it produces.

Web SaaS using Gitflow. A team deploying a web app daily, with no need to support old versions, runs Gitflow because that is what they set up two years ago. Every release requires cutting a release/* branch, running QA against it, then merging into both main and develop. For a daily release, that is daily merge overhead. Engineers complain that "Git is slow." Git is not slow; the workflow is wrong for the cadence.

Small team using Gitflow. A four-person startup picks Gitflow on day one because it looks structured. Now every feature requires creating a feature/* branch, opening a PR to develop, having someone review it, merging, then later cutting a release/* branch even for one-line changes. The extra work is paying for parallel-version support the team will never need. Productivity is measurably worse than the simpler alternative.

Trunk team pretending to use Gitflow. A team has develop and main branches by convention but, in practice, merges directly to develop whenever, and merges develop to main whenever they feel like deploying. There are no real release branches. There is no real hotfix process. The Gitflow name is decoration on what is essentially TBD with extra branches. This is fine in practice — it just means the team should drop the pretence and admit they are not running Gitflow.

If you see your team in any of these, the cost is real and the fix is in post #8.

A note on tooling

Tools matter less than people make them sound. The git-flow AVH command-line tool exists and adds shortcuts (git flow feature start xyz), but you do not need it. Plain git commands work fine. The tool is an alias for what you would already do.

What matters more is branch protection. On GitHub, GitLab, or Bitbucket, enforce these rules on main and develop:

No direct pushes.
Require PR review.
Require status checks to pass before merging.

GitHub's branch protection docs cover the full set of options. The same protections make Gitflow safer and TBD safer.

Three teams who chose Gitflow on purpose

To make this concrete, three real-shape teams where Gitflow is the right call.

Team A: Mobile SDK, 80 engineers. Releases v3.0, v3.1, v3.2 over a year. Each major version supported for 18 months. Customer apps update on their own schedule. Hotfixes ship into old release/* branches monthly. Gitflow's release/* and hotfix/* branches are exactly the model they need.

Team B: Medical device firmware, 12 engineers. FDA-regulated. Every release goes through a formal QA cycle on a frozen build. Audit logs of every change are required. A release/* branch held stable during QA is the artifact the auditor wants. TBD would require building custom audit tooling; Gitflow gives it for free.

Team C: Enterprise on-premise database, 40 engineers. Customers run the software on their own hardware. The team supports the last three minor versions, going back two years. Security patches go into all three. Without long-lived release branches, this is impossible.

What a working Gitflow week looks like

A concrete picture of Gitflow done well. Imagine a 40-engineer team shipping a versioned SDK on a 6-week minor-release cadence.

Monday, week 1 of a cycle. v3.2 was just released. develop is fresh, with the merge from release/3.2 just landed. Engineers branch new feature/* branches off develop and start the next sprint's work.

Tuesday–Thursday. Features land on develop via PRs. CI runs the full test suite on each merge. Some features are large and span multiple PRs; each PR is small and individually reviewable, and the larger feature is wrapped in a code-level flag that defaults to off.

Week 4. Feature freeze. A release/3.3 branch is cut from develop. After this, only bug fixes go on release/3.3. New features continue landing on develop for the next cycle.

Weeks 4–5. QA runs against release/3.3. Bugs found result in fixes committed directly to release/3.3 and back-merged into develop. Each back-merge is a single PR with a clear message.

Week 6, ship day. release/3.3 is merged into main and tagged v3.3.0. The release branch stays alive for the support window (say, 3 months) to receive any v3.3.x patches.

Mid-cycle: hotfix. A customer reports a critical bug in v3.2. Engineer branches hotfix/3.2.1-csrf-leak from main at the v3.2.0 tag (or from release/3.2). Fixes. Merges into main (tagged v3.2.1) and into develop (so the fix appears in v3.3 too) and into release/3.3 if the cycle is far enough along that the fix needs to be there.

This is the workflow as designed. Note that every branch has a clear purpose, every merge has a known direction, and every release is tagged and identifiable. The structure is heavy. For a versioned SDK with multi-version support, the structure is paying for what it costs.

Common myths

Myth 1: "Driessen retracted Gitflow." Wrong. He added a note in 2020 saying continuous-delivery web teams should use something simpler. He did not retract or deprecate the model. For versioned software with parallel support timelines, his post still stands.

Myth 2: "Gitflow is too complex for any modern team." Partly wrong. Gitflow is more complex than GitHub Flow. That complexity is wasted on simple cases. For genuinely complex release management — multiple supported versions, regulated change control — that complexity is the simplest tool that does the job.

Myth 3: "You need the git-flow tool to do Gitflow." Wrong. The model is just a discipline about which branches you create, where they branch from, and where they merge back. Plain git checkout -b release/3.0 works fine. The tool is convenience, not requirement.