GitFlow Workflow: The Traditional Branching Model, and When It Still Makes Sense

If you've worked at a company with quarterly releases, a QA team, and a "release candidate" Slack channel, you've almost certainly touched GitFlow. Vincent Driessen published it in 2010, back when most teams shipped software on a schedule rather than on every merge. It became the default answer to "how should we branch?" for about a decade.

These days it gets a lot of side-eye. Some of that is deserved. But GitFlow isn't dead, it's just often used on projects it was never meant for. Let's go through how it actually works, where it hurts, and how to run it without making your team miserable.

The core idea

GitFlow uses two long-lived branches and three kinds of short-lived ones.

Long-lived:

• main (or master): always matches what's in production. Every commit here is a release, and it's tagged.
• develop: the integration branch. It holds the next release's work.

Short-lived:

• feature/*: branched from develop, merged back into develop.
• release/*: branched from develop when you're ready to stabilize. Only bug fixes go here. Merged into both main and develop.
• hotfix/*: branched from main to patch production fast. Merged into both main and develop.

The flow, visualised

Notice that release and hotfix branches merge twice. That's the part people forget, and it's the most common source of "why is this bug back?" incidents.

Working through it with real commands

Starting a feature

git checkout develop
git pull origin develop
git checkout -b feature/user-profile

# ...work, commit, push...
git push -u origin feature/user-profile

When it's done, open a PR into develop. I'd recommend --no-ff merges here so the feature stays visible as a unit in history:

git checkout develop
git merge --no-ff feature/user-profile
git branch -d feature/user-profile

Cutting a release

git checkout develop
git checkout -b release/1.4.0

# bump version, update changelog, fix last-minute bugs
git commit -am "Bump version to 1.4.0"

Once QA signs off:

git checkout main
git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"

git checkout develop
git merge --no-ff release/1.4.0

git branch -d release/1.4.0
git push origin main develop --tags

Hotfixing production

git checkout main
git checkout -b hotfix/1.4.1

# fix the bug
git commit -am "Fix null pointer in payment handler"

git checkout main
git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Hotfix 1.4.1"

git checkout develop
git merge --no-ff hotfix/1.4.1
git branch -d hotfix/1.4.1

One gotcha: if a release/* branch is open when you hotfix, merge the hotfix into the release branch instead of develop. It'll reach develop when the release merges back.

Branch lifecycle at a glance

What GitFlow is good at

• Scheduled, versioned releases. Mobile apps, desktop software, firmware, on-prem products, anything where you can't just redeploy.
• Supporting multiple versions in production. If customers are on v2.3 and v3.1 at the same time, you need long-lived release lines.
• Formal QA and sign-off. The release branch gives testers a stable target while developers keep moving on develop.
• Clear audit trail. main plus tags gives you a clean history of exactly what shipped.

Where it hurts

Be honest with yourself about these before you adopt it.

1. Long-lived branches drift. A feature branch that lives for three weeks will conflict with everything. The longer it lives, the worse the merge.
2. Double merges are easy to botch. Forget to merge a hotfix back into develop and you've re-introduced a bug.
3. It slows down CI/CD. If you deploy multiple times a day, develop → release → main is pure ceremony.
4. Two "sources of truth." Is develop the truth, or main? New joiners ask this constantly.
5. Heavy process for small teams. A team of four doesn't need five branch types.

Even Vincent Driessen added a note to his original post saying that if you're doing continuous delivery, you should probably use something simpler. Worth reading.

Best practices if you do use it

• Keep feature branches short. Days, not weeks. If a feature is huge, use feature flags and merge incomplete work behind a flag.
• Rebase feature branches on develop regularly (git rebase develop) so integration pain stays small.
• Protect main and develop. Require PRs, reviews, and passing CI. Nobody should push directly.
• Automate tagging and changelogs. Tools like semantic-release, standard-version, or git-cliff remove the human-error part.
• Use a consistent naming convention. feature/JIRA-123-short-description pays off every time you search through branches.
• Delete merged branches. Turn on "auto-delete head branches" in GitHub/GitLab.
• Automate the back-merge. A small CI job that opens a PR from main to develop after every release or hotfix saves you from forgotten merges.
• Consider git-flow CLI extensions (git flow feature start, etc.) if your team likes commands over memorizing sequences. Just make sure everyone understands what they do underneath.

Quick decision check

GitFlow is a reasonable fit if most of these are true:

• You ship versioned releases, not continuous deploys
• You maintain more than one production version
• You have a dedicated QA/stabilization phase
• Your team is large enough that integration isolation helps

If you're nodding at fewer than two of these, look at GitHub Flow or Trunk-Based Development instead.

Wrapping up

GitFlow solves a real problem: coordinating work when releases are infrequent, expensive, and need stabilization. It just solves it with a lot of machinery. Use it deliberately, automate the boring parts, and don't be afraid to move off it when your release cadence changes.

If this helped you, I'd really appreciate your support. You can buy me a coffee here: buymeacoffee.com/vatul16 ☕

Thanks for reading!