Git Branching Strategies: Trunk vs Gitflow vs GitHub Flow

Every team eventually fights about branching strategy. The fight is rarely about Git — it is about how often you ship, how scary your releases are, and how confident you are in your tests. Three strategies dominate: trunk-based, gitflow, and GitHub flow. They are not interchangeable, and picking the wrong one slows you down for years.

The shared vocabulary

Before comparing, set a baseline:

• Trunk: the main long-lived branch, usually called main.
• Feature branch: short-lived branch off main for a single change.
• Release branch: a branch dedicated to stabilizing a version before shipping.
• Hotfix branch: an emergency branch to patch production without pulling in unfinished work.

Every strategy uses some subset of these. The differences are in how long they live and what merges where.

Trunk-based development

One long-lived branch: main. Everything else lives for hours, not days.

git checkout main
git pull
git checkout -b small-fix
# ... edits ...
git commit -am "fix flaky retry"
git push -u origin small-fix
# open PR, merge within hours

Rules:

• Branches under 24 hours old. Ideally under 8.
• Work in progress lives behind feature flags, not branches.
• main is always releasable. CI runs on every push and gates merges.

Best fit: SaaS products, fast-moving startups, anyone deploying multiple times per day. Google, Facebook, and Netflix all run something close to this.

Trade-off: requires strong CI, feature flags, and code-review discipline. Without those, main becomes broken weekly.

Gitflow

The classic, ceremonial model with five branch types: main, develop, feature/*, release/*, hotfix/*.

Day-to-day work happens on feature branches that merge into develop. When you are ready to ship, you cut a release/x.y.z branch off develop, stabilize it, then merge into both main and develop. Tags on main mark releases. Hotfixes branch off main and merge into both.

git checkout develop
git checkout -b feature/payments
# ... work ...
git push origin feature/payments
# PR into develop

# release time
git checkout develop
git checkout -b release/1.4.0
# QA, bugfixes
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

Best fit: shrink-wrap software with quarterly releases, regulated industries that need clear audit trails, multi-version support where you maintain v1 and v2 simultaneously.

Trade-off: complex, slow, easy to get wrong. Long-lived branches breed nasty merge conflicts. For a small SaaS team, gitflow is overkill and actively harmful.

GitHub Flow

The pragmatic middle ground. One long-lived branch (main), short-lived feature branches, and deployment from main after every merge.

git checkout main
git pull
git checkout -b add-search-filter
# ... edits ...
git commit -am "add search filter"
git push -u origin add-search-filter
# open PR, review, merge to main
# deploy main

Rules:

• One branch off main per change.
• Pull request, review, CI, merge.
• Deploy main after every merge — sometimes automatically.

Best fit: open-source projects, mid-sized SaaS teams, anyone who deploys daily but not hourly. The default for most GitHub-hosted teams.

Trade-off: feature branches can live longer than they should, especially without code-owner enforcement. Without feature flags, big changes still cause friction.

Quick comparison

Strategy        Long-lived branches    Release cadence       CI strictness
Trunk-based     1 (main)               Many per day          Very high
GitHub Flow     1 (main)               Daily                 High
Gitflow         2 (main, develop)      Weeks to months       Moderate

Hotfixes — the under-discussed test

A great way to evaluate any strategy is “how painful is a 2am production fix?”

• Trunk-based: branch off main, push a tiny PR, deploy in 20 minutes. Easy.
• GitHub Flow: same as trunk-based. Easy.
• Gitflow: branch off main, fix, merge into main, tag, and merge back into develop. Forgetting the back-merge causes regressions.

If your hotfix flow has more than three steps, your branching model has more ceremony than your team’s actual reliability needs.

Common anti-patterns

• Long-lived feature branches: every day a branch lives past 48 hours, the cost of merging it doubles.
• Squash everything blindly: useful for noisy work, but you lose the history of why a change took the shape it did.
• No protected branches: anyone can force-push to main and break the world.
• PRs with 30 commits and 4000 lines: nobody reviews them carefully. Split into smaller PRs.
• Skipping CI on “trivial” changes: that is exactly the change that breaks production.

What I recommend

For most teams reading this:

1. Start with GitHub Flow. It is the default for a reason.
2. Move to trunk-based when you ship more than once a day, have strong CI, and adopt feature flags.
3. Use gitflow only if you maintain multiple shipped versions in parallel or work in a regulated industry that demands explicit release branches.

The strategy is not the goal — short-lived branches, strong CI, and confident releases are. Whichever model gets you there fastest is the right one for your team.

A note on rebasing vs merging

This argument is theological. The pragmatic answer: rebase your own in-progress branch as often as you like to keep history clean; merge into shared branches without rewriting their history. Never rebase shared branches that other people have based work on. That single rule resolves 90% of branching pain.