Trunk-based development and Git Flow are the two dominant branching strategies, and the debate between them has shaped two decades of how teams ship software. The honest answer is that they fit different team sizes, release cadences, and risk profiles. Picking based on what your team actually does is more useful than picking based on what the loudest blog post recommends.
This post is the direct comparison: how each works, where each fits, and the patterns teams use when the textbook version of either fails them.
Trunk-Based Development
In its strictest form: one long-lived branch (main), with short-lived feature branches (or no branches at all) that merge to main multiple times per day.
main: ──A──B──C──D──E──F──G──H──I─→
╲ ╲ ╲
X────Y Z (short feature branches, merged within hours)
Properties:
- Every commit on main is releasable
- Branches live for hours, not weeks
- Continuous integration runs on every push
- Feature flags hide incomplete work from users
- Releases are made from main (continuously or on schedule)
The model is simple: there is one place where the truth lives, and it is always shippable.
Git Flow
In its standard form: main for production, develop for ongoing work, feature branches for new features, release branches for stabilization, hotfix branches for emergency fixes.
main: ──────A───────────B─────── (production-tagged)
develop: ──C──D──E──F──G──H──I──J─→
╲ ╲ ╲ ╲
feat-1 feat-2 feat-3 (long-lived, merged when complete)
│
└── release-1.0 ── (stabilization)
Properties:
- Multiple long-lived branches with distinct purposes
- Feature branches live for days to weeks
- Release branches stabilize a version before going to production
- Hotfix branches branch from main, merge to both main and develop
The model is structured: there is a place for each kind of work, and the branches enforce process.
Where Trunk-Based Wins
Trunk-based development excels when:
- Continuous delivery is the goal. Daily or hourly deploys assume daily or hourly merges to main.
- The team is engineering-mature. Trunk-based requires high test coverage, feature flags, and CI discipline.
- The product has many small users. A bad commit affects everyone briefly; better to ship and fix than to delay.
- The team is medium-sized (10–100 engineers). At this size, the coordination overhead of Git Flow exceeds its benefits.
The DORA research consistently shows trunk-based correlating with elite delivery performance. The mechanism is simple: less coordination overhead, faster integration of changes, smaller batches.
Where Git Flow Wins
Git Flow makes sense when:
- Releases are infrequent. A monthly or quarterly release cadence benefits from a stabilization phase.
- Multiple versions in support. A vendor shipping 2.x and 3.x in parallel needs branches that track each.
- High-risk changes need staging. A feature that requires weeks of QA cannot just merge to a continuously-deployed main.
- Customers explicitly choose when to upgrade. Enterprise software with annual release cycles.
- The team is small or has limited CI infrastructure. Trunk-based without strong CI is just "broken main."
Most desktop software, on-prem products, and enterprise releases still use a Git Flow-like model. The constraints have not gone away.
The Hybrid Most Teams Use
Strict Git Flow is rare in practice. Strict trunk-based with sub-hour branches is also rare. Most teams use a hybrid:
- One long-lived main branch (shippable, deployed to production)
- Short feature branches (1–5 days) that merge to main via PR
- Squash merges to keep main's history clean
- Feature flags for incomplete work
- Release tagging rather than release branches
This is closer to trunk-based than Git Flow. It is sometimes called "GitHub Flow," sometimes "trunk-based with PRs," sometimes just "how we work." Whatever the name, it is the dominant pattern for SaaS in 2026.
Feature Flags Make Trunk-Based Practical
The trunk-based pattern only works if incomplete features can ship without users seeing them. Feature flags are the mechanism.
if (Feature::for($user)->active('new-checkout-flow')) {
return $this->newCheckoutFlow($request);
}
return $this->legacyCheckoutFlow($request);
A half-done feature merges to main behind a flag (new-checkout-flow: off). The code is on production but nobody sees it. The flag flips on when the feature is ready — gradually, by user segment, by tenant, however.
Without feature flags, trunk-based forces you to either keep changes in branches until they are fully done (long branches), or ship incomplete features (bad UX). Flags make the middle path work.
Release Cadence
Branching strategy and release cadence are coupled:
- Continuous deployment (every merge to main) requires trunk-based or close to it. Long branches break it.
- Daily releases work with either.
- Weekly or monthly releases can work with trunk-based plus tags, or Git Flow with release branches.
- Quarterly or annual releases need Git Flow's stabilization phase.
If you want daily releases and currently use Git Flow, the branching strategy is your bottleneck.
The Coordination Cost
Git Flow's biggest hidden cost is coordination. Long-lived feature branches diverge from main. Merging back requires resolving conflicts that have accumulated over days or weeks. The cost compounds with team size.
main: ──A──B──C──D──E──F──G──H─→ (10 commits in 2 weeks)
feature: ────╲X──Y──Z─── (3 commits in 2 weeks, behind by 7)
When feature merges back to main, the engineer reconciles 7 commits' worth of drift. With 10 engineers each doing this, the coordination tax is real.
Trunk-based eliminates this because branches are too short to drift far. The cost is paid up front in test/CI investment, not in ongoing coordination.
What About Bug Fixes?
In Git Flow, hotfixes are a separate branch type with a specific merge pattern. In trunk-based, a fix is just another short branch to main, deployed immediately.
The trunk-based model works because main is always shippable. If main is not shippable, you have a different problem — the fix is the smaller issue.
What About Long-Running Features?
The "weeks-long feature" objection to trunk-based is real but has answers:
- Break the feature into shippable slices
- Hide work behind a feature flag
- Use branch by abstraction (introduce the abstraction in main, ship behind the flag)
- Land the infrastructure first, then the feature on top
A feature that genuinely cannot be sliced is rare. When it appears, a short-lived feature branch (1–2 weeks) is acceptable. Just do not make it the norm.
Migration Between Strategies
Going from Git Flow to trunk-based:
- Adopt feature flags before changing branching
- Shorten branch lifetimes gradually (target 1 day instead of 1 week)
- Eliminate develop; merge directly to main
- Replace release branches with release tags
A multi-week shift, sometimes longer if the test infrastructure needs work first. The investment is real but the payoff in coordination overhead is significant.
Going from trunk-based to Git Flow is also possible but rare. Usually a sign that the team is shipping less reliably and wants more process. Address the underlying issue first.
Common Mistakes
- Trunk-based with no feature flags. Incomplete features visible to users. Reverts every other day.
- Trunk-based with weak CI. Broken main is the new normal. Velocity tanks.
- Git Flow on a daily release cadence. All the overhead, none of the benefit.
- Long-lived feature branches in any model. Coordination cost compounds; eventually the branch is too far from main to merge cleanly.
- Skipping the squash on merge. Main's history becomes a tangle that is impossible to navigate.
The Pragmatic Choice
For most SaaS teams in 2026: trunk-based with PRs (one or two-day branches), feature flags for in-progress work, and tags for releases.
For desktop and on-prem software with infrequent releases: a Git Flow variant remains appropriate. The stabilization phase exists for a reason.
For everyone in between: pick based on release cadence, team size, and what your test infrastructure can support. The branching strategy should fit the work, not the other way around.
Working with a branching strategy that has not kept up with how the team actually wants to ship? We help teams move toward strategies that match their release cadence and test maturity. scopeforged.com