GitFlow - The Branching Strategy Everyone Uses But Nobody Should

Back in 2010, Vincent Driessen published a blog post about his team's branching strategy and accidentally created a monster. What started as "here's something that worked for us" somehow became gospel. Now every team feels like they need to use GitFlow because it sounds professional and structured.

Here's the thing nobody tells you: GitFlow is way too complex for what most teams actually need. Last year I watched a team spend two weeks trying to merge a month-old feature branch. The conflicts were so fucked they just rewrote the entire feature. That's not unusual - I've seen this pattern over and over where teams waste more time managing GitFlow than actually shipping code.

The Five-Branch Circus

The GitFlow branching model in all its overcomplicated glory

GitFlow uses five different branch types because apparently two wasn't enough:

The "permanent" branches:

• master: Supposedly production-ready code, but half the time it's broken because someone fucked up a hotfix merge
• develop: Where all the feature branches go to die. Gets so messy you'll pray for merge conflicts just to end the suffering

The "temporary" branches (that live forever):

• feature/*: Individual features that were supposed to be short-lived but somehow take 3 months
• release/*: Pre-production testing branches that become permanent because your QA process is garbage
• hotfix/*: Emergency fixes that you'll forget to merge back to develop, breaking everything next release

The git-flow tools are basically abandoned at this point. Tried setting them up recently and it was a nightmare - tools just break on newer systems and nobody's maintaining them anymore. The original maintainer gave up years ago. Even the "active" forks throw cryptic errors constantly. Most developers waste hours debugging install issues then give up and just use regular git commands, which defeats the entire point of having GitFlow tooling.

GitHub stopped pushing GitFlow years ago in favor of their simpler GitHub Flow. GitLab created their own "GitLab Flow" specifically because GitFlow was too complex. Even Atlassian, who made a fortune selling GitFlow tutorials, now admits it's only suitable for teams with scheduled releases.

The Merge Conflict Nightmare

GitFlow proponents claim it reduces merge conflicts. That's bullshit.

Here's what actually happens: You branch feature/user-login from develop on Monday. By Friday, five other developers have merged their features to develop. Your branch is now hopelessly behind. You can either:

1. Merge develop into your feature branch (creating a ugly merge commit)
2. Rebase your feature branch (but GitFlow purists say this breaks the "visual history")
3. Live with the inevitable merge conflicts when you finally merge

I've watched teams spend entire afternoons untangling GitFlow merge conflicts that wouldn't exist with a simpler workflow. Had one feature branch sitting around for weeks - when we finally tried to merge it, conflicts in damn near every file. Took longer to resolve the conflicts than it did to write the original feature.

Your daily reality with GitFlow: merge conflicts everywhere

When GitFlow Actually Works

GitFlow isn't completely useless. It works well when you have:

• Scheduled releases (monthly/quarterly) where you can't deploy whenever you want
• Large teams (20+ developers) who need coordination structure
• Enterprise environments where everything needs approval and documentation
• Mobile apps where Apple/Google control your deployment schedule

But if you're a web team deploying multiple times per day? GitFlow will slow you down and piss everyone off. The whole point of continuous deployment is to ship fast and fix fast. GitFlow's ceremony directly opposes this - you'll spend more time managing branches than shipping features.

GitFlow complexity vs GitHub Flow simplicity - guess which one actually works for most teams

The Tools Are Mostly Broken

GitFlow tool ecosystem - complex workflows require complex tooling that constantly breaks

IDE support is hit-or-miss:

• VS Code GitFlow extensions break randomly and the good ones get abandoned. I've installed three different extensions over the past year and all of them stopped working after VS Code updates.
• JetBrains has decent built-in support but it's still too complex for junior developers who just want to commit their code
• GitKraken makes it visual but you're still managing five different branch types, which means five different ways to fuck up your repository

The visual representation of GitFlow complexity - this is what your team will need to understand

SourceTree's GitFlow integration works until you need to do something slightly outside the happy path, then you're back to the command line debugging git-flow bash scripts. Tower and other Git GUI clients provide GitFlow integration but they can't hide the fundamental complexity. Even SourceTree's own documentation warns about the complexity and suggests considering simpler alternatives - which should tell you everything you need to know.

The Setup Nightmare

Getting GitFlow running is like setting up a Rube Goldberg machine to make toast. You've got two options, both terrible:

Using the abandoned git-flow tools:

git flow init

This command asks a bunch of questions about branch naming then crashes with some bash error about sed or missing dependencies. The main git-flow repo hasn't been updated since 2019. The "improved" git-flow-avh fork breaks on macOS Ventura and throws zsh: command not found: git-flow even after installation. Stack Overflow has 400+ threads of people asking why git-flow just... doesn't work.

Manual setup (because the tools suck):

git checkout -b develop master
git push -u origin develop
## Now manually track which branches are what type
## Hope nobody forgets the naming conventions

Most teams end up doing it manually because the tools break constantly. If you need special tools to manage your branching strategy, maybe your branching strategy is too fucking complex. Even ThoughtWorks Technology Radar lists GitFlow under "Hold" status, which is corporate speak for "please stop using this garbage."

Feature Development Hell

Here's where GitFlow really starts to fuck with you. Every feature needs its own branch, and you better hope you named it right.

Starting a feature (if the tools work):

git flow feature start new-authentication
## Pray this doesn't crash with some cryptic bash error

What actually happens:

git checkout -b feature/new-authentication develop
## Because git-flow broke again and you're doing it manually

Finishing a feature (theory vs reality):

git flow feature finish new-authentication
## Should merge to develop and clean up
## Actually crashes because someone pushed to develop while you were working

What you end up doing:

git checkout develop
git pull origin develop
git merge feature/new-authentication
## Deal with conflicts manually
git branch -d feature/new-authentication
## Remember to clean up the remote branch too

Feature branches are supposed to be short-lived. In practice, they sit around for weeks getting stale while your team argues about code review comments. I've seen feature branches that were older than the sprint cycle they were supposed to fit into. The longer they sit, the more painful the merge becomes when you finally get around to it.

Release Branch Purgatory

Release branches are where features go to die slowly. You create one thinking it'll be a quick staging area. Two weeks later, you're still fixing "critical" bugs that somehow weren't critical during development.

Creating a release branch:

git flow release start 1.2.0
## Creates a branch that will live forever

What happens next:

1. QA finds bugs that were somehow missed during development
2. Product manager wants "just one more tiny feature"
3. You spend weeks fixing things that should have been caught earlier
4. The release branch diverges so far from develop that merging back is a nightmare

Finishing a release (if you're lucky):

git flow release finish 1.2.0
## Supposed to merge to master, tag, and merge back to develop
## Actually creates merge conflicts because develop moved on without you

What actually happens:

## Merge conflicts everywhere
## Manual conflict resolution
## Pray you didn't break anything
## Spend hours making sure both branches are in sync

Release branches sound great in theory. In practice, they become long-lived integration nightmares that block development for weeks.

Hotfix Hell at 3AM

Hotfixes are supposed to be quick emergency fixes. In GitFlow, they're anything but quick.

The theory:

git flow hotfix start critical-security-fix
## Quick fix from master, deploy, done

The reality:
Production is down, you need a quick fix, but GitFlow forces you to merge to three different branches while your users are screaming. Last time this happened to me, git flow hotfix finish threw an error about "working tree not clean" even though git status was clean. Spent 20 minutes at 2AM googling git-flow bash script bugs while our API was returning 500s. By the time I gave up and did it manually, I could've fixed the issue and deployed it twice.

What you actually do:

git checkout master
git pull origin master
git checkout -b hotfix/fix-prod-now
## Fix the issue
git checkout master
git merge hotfix/fix-prod-now
git push origin master
## Deploy
git checkout develop
git merge hotfix/fix-prod-now
## Deal with conflicts at 4AM
## Forget to tag the release
## Remember to tag it the next day (maybe)

By the time you're done with GitFlow's hotfix ceremony, you could have fixed the issue three times with a simpler workflow.

The Tooling Wasteland

The "modern" GitFlow tooling ecosystem is like a graveyard of abandoned projects and broken promises.

GitHub Actions for GitFlow:
Most GitHub Actions for GitFlow are basically abandoned. Tried using a few different ones and they all had issues - either they don't work properly, assume workflows that don't match reality, or just fail with cryptic errors. Jenkins GitFlow plugins are similarly outdated and most teams have given up on specialized GitFlow tooling entirely.

IDE Support:

• VS Code: Extensions constantly break and get abandoned
• JetBrains: Built-in support is decent but adds complexity for simple tasks
• GitKraken: Pretty UI that can't fix the fundamental complexity issues

GitKraken and other GUI tools provide visual GitFlow support, but pretty interfaces can't hide the fundamental complexity problems - you're still managing five different branch types with complex merge rules.

Performance? What Performance?

GitFlow kills performance in several ways:

• Branch explosion: You'll have dozens of stale feature branches nobody cleaned up
• Merge complexity: Every release involves merging between multiple branches
• Repository bloat: All those merge commits and branch references add up

Large repos with GitFlow become unusable. Small repos become large repos faster with GitFlow because of all the branching overhead. I've worked on repos where git log --oneline --graph was completely unreadable because of all the GitFlow merge commits and branch noise. At some point you need to run git gc constantly just to keep things responsive.

CI/CD Integration Nightmare

GitFlow workflow complexity - imagine trying to build CI/CD pipelines for all these different branch types

GitFlow and CI/CD hate each other:

• Feature branches: Deploy to where? You've got 15 of them
• Develop branch: Constantly broken because everyone merges half-finished features
• Release branches: Your QA environment is tied up for weeks testing release candidates
• Master branch: Supposedly production-ready, but nobody deploys from it directly

Most teams end up building complex CI/CD workflows just to handle GitFlow's branching complexity. You'll spend more time managing your build pipeline than writing features.

GitFlow CI/CD pipelines require separate environments for feature branches, develop, release branches, and master - creating overcomplicated solutions to self-inflicted problems where simple trunk-based development would work better.

The truth: GitFlow was designed for a world where CI/CD didn't exist. Trying to retrofit modern deployment practices onto GitFlow is like putting racing stripes on a horse-drawn carriage. Elite performing teams use trunk-based development, not GitFlow. There's a reason for that.

Trunk-based development: simple, effective, and actually works with CI/CD

By now, you're probably thinking either "This guy is exaggerating" or "Holy shit, I'm glad we never tried GitFlow." Both reactions are valid. But since people keep asking the same questions about GitFlow - mostly variations of "Surely it can't be this bad?" - let's address the most common arguments for why teams think they need GitFlow's complexity.