Trunk-Based Development vs. Git Flow

A decision document comparing two branching strategies. Evaluates each approach against our CI/CD maturity, team velocity, and DevOps best practices — then recommends a path forward.

Team: Decision Document

Owner: William Weeks-Balconi

Updated: April 2026

Audience: Engineering, DevOps, Product Management, Leadership

---

Table of Contents

1. Executive Summary
2. What Is Git Flow?
3. What Is Trunk-Based Development?
4. Side-by-Side Comparison
5. Git Flow — Pros and Cons
6. Trunk-Based Development — Pros and Cons
7. Industry Evidence
8. Impact on Our Team
9. Recommendation
10. References

---

1. Executive Summary

Recommendation: Adopt trunk-based development. The industry consensus, our CI/CD maturity, and our team's pain with long-lived branches all point the same direction.
!panel

We currently follow a Git Flow–style branching strategy with develop, master, feature branches, release branches, and hotfix branches. While Git Flow served the industry well when it was introduced in 2010, it predates modern CI/CD practices and actively works against continuous integration.

This document presents a fair comparison of both approaches and recommends trunk-based development based on:

• DORA/Accelerate research — trunk-based development is a key predictor of elite DevOps performance
• Atlassian's official position — Git Flow is now labeled a "legacy workflow"
• The creator's own retraction — Vincent Driessen recommends against Git Flow for teams doing continuous delivery
• Our own experience — long-lived branches drift, merge conflicts compound, and CI/CD pipelines can't validate what actually ships

---

2. What Is Git Flow?

Git Flow was introduced by Vincent Driessen in 2010 as a branching model for git. It defines five branch types:

Branch	Lifetime	Purpose
master (or main)	Permanent	Production-ready code
develop	Permanent	Integration branch for features
feature/*	Days–weeks	New feature development
release/*	Days	Stabilization before production
hotfix/*	Hours–days	Emergency production fixes

Git Flow Workflow Diagram

How It Works

1. Developers create feature/* branches from develop
2. Completed features merge back into develop
3. When ready for release, a release/* branch is cut from develop
4. Release branch gets final testing and bug fixes
5. Release merges into both master and back into develop
6. Hotfixes branch from master, merge into both master and develop

The key assumption: developers work in isolation until their feature is "done," then integrate.

---

3. What Is Trunk-Based Development?

Trunk-based development (TBD) is a branching strategy where all developers commit to a single shared branch — main (the "trunk") — at least once per day. Short-lived branches (hours, not days) may be used for code review, but they never diverge far from trunk.

Branch	Lifetime	Purpose
main (trunk)	Permanent	Single source of truth — always releasable
Short-lived branches	Hours	Code review via PR, merged same day

Trunk-Based Development Workflow Diagram

How It Works

1. Developers pull latest main, make small changes, push frequently
2. Short-lived branches (optional) exist only for PR review — merged within hours
3. CI pipeline runs on every push to main — build, test, lint, scan
4. main is always in a releasable state
5. Feature flags hide incomplete work from users without hiding code from CI
6. Releases are tags or automated deployments from main — no release branches

The key assumption: feedback is most valuable when it's fast and continuous, not delayed until "done."

---

4. Side-by-Side Comparison

Dimension	Git Flow	Trunk-Based Development
Branch count	5+ types, many concurrent	1 permanent + short-lived
Integration frequency	When feature is "done" (days–weeks)	At least daily, often multiple times
Merge conflicts	Frequent, large, painful	Rare, small, easy
CI/CD compatibility	Poor — which branch is "truth"?	Native — trunk is always truth
Deployment speed	Slow — release branch stabilization	Fast — trunk is always releasable
Rollback strategy	Hotfix branches	Revert commit or feature flag
Code review	PR on feature branch merge	PR on short-lived branch (same day)
Risk of drift	High — branches diverge silently	Low — constant integration
Testing confidence	Tests run on approximation of production	Tests run on actual production code
Team coordination	Low — isolated work	High — shared ownership
Learning curve	Complex branch management	Requires discipline around small commits
DORA classification	Associated with low/medium performers	Key predictor of elite performers

---

5. Git Flow — Pros and Cons

Pros

• Clear separation of concerns — each branch type has a defined purpose
• Familiar to many developers — widely taught and documented since 2010
• Explicit release process — release branches provide a stabilization window
• Parallel release tracks — can maintain multiple release versions simultaneously (useful for packaged software)

Cons

• Works against continuous integration — branches are designed to isolate change; CI is designed to expose change. These are mutually exclusive goals.
• Long-lived branches drift — the longer a feature branch lives, the more it diverges from reality. Merge day becomes pain day.
• "Which branch is truth?" — develop isn't what ships. master may be missing hotfixes not yet merged back. Neither branch definitively represents production state.
• Delayed feedback — developers don't learn their changes conflict until merge time, often after days or weeks of now-wasted work
• Complex branch management — five branch types require tooling, discipline, and cognitive overhead
• Incompatible with CI/CD — you cannot continuously integrate if code lives on isolated branches for days

!panel(warning)
The creator agrees. Vincent Driessen updated his original Git Flow article: "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."
!panel

---

6. Trunk-Based Development — Pros and Cons

Pros

• Continuous integration by design — everyone integrates to trunk at least daily. There is one truth, one version, one pipeline.
• Small, frequent merges — conflicts are small and caught immediately, not compounded over weeks
• Fast feedback — CI runs on actual production code after every push. You know within minutes if your change is safe.
• Simpler branch model — one permanent branch. Less tooling, less cognitive overhead, less ceremony.
• Higher deployment frequency — trunk is always releasable, so you can deploy on demand
• DORA-validated — the Accelerate research program (30,000+ professionals, 7 years of data) identifies trunk-based development as a key technical practice of elite-performing teams

Cons

• Requires CI discipline — the pipeline must be fast, reliable, and comprehensive. Broken trunk blocks everyone.
• Feature flags needed for large features — incomplete work must be hidden from users (but not from CI). This adds a small operational cost.
• Cultural shift — developers used to long-lived branches need to learn to work incrementally, commit smaller, and merge faster
• Less suitable for packaged software — if you ship versioned releases to customers who control their own upgrades, release branches may still be necessary (this does not apply to our cloud-deployed services)

---

7. Industry Evidence

DORA / Accelerate Research

The DevOps Research and Assessment (DORA) program — the largest study of software delivery performance — consistently identifies trunk-based development as a key predictor of elite DevOps performance.

From Accelerate (Forsgren, Humble, Kim):

"Teams that practice trunk-based development, where developers work in small batches and merge into a shared trunk at least daily, achieve higher software delivery performance."

Elite-performing teams:

• Deploy on demand (multiple times per day)
• Lead time for changes: less than one day
• Change failure rate: 0–15%
• Time to restore service: less than one hour

All of these metrics are enabled by trunk-based development and impeded by long-lived branches.

Atlassian's Official Position

Atlassian, the company behind Bitbucket and the original popularizer of Git Flow documentation, now states:

!panel(note)
"Git Flow is a legacy git workflow. This was originally a disruptive and novel strategy for managing git branches. Git Flow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices."
— Atlassian Git Tutorials
!panel

Vincent Driessen's Retraction

The inventor of Git Flow added this note to his original 2010 article:

"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."

Dave Farley — Continuous Delivery

Dave Farley, co-author of the foundational Continuous Delivery book, explains why Git Flow is incompatible with CI/CD:

!embedGit Flow Is A Bad Idea — Dave Farley

Key points from the video:

• Branches isolate change; CI exposes change — these are mutually exclusive goals
• "What if engineers didn't hold on to modules for more than a moment?" — the original CI vision from its inventors
• The "truth" problem — in Git Flow, neither develop nor master definitively represents what's in production
• If develop and master are kept close, what's the point of both? — the closer they are, the less Git Flow adds; the further apart, the more risk
• Daily integration is the minimum — if your feature takes longer than a day, you can't wait until it's finished to integrate. If it takes less than a day, why create a feature branch?
• The data is in — continuous integration works better, even though it requires adapting how we work

---

8. Impact on Our Team

Where We Are Today

• We already have automated CI pipelines with build, test, and lint stages
• We already deploy regularly to cloud environments
• Our pain: long-lived feature branches drift, merge conflicts compound, and our CI pipelines validate branch code that may never match what ships to production

What Trunk-Based Development Changes

Current (Git Flow)	With Trunk-Based
Feature branches live for days–weeks	Short-lived branches merge within hours
"Merge day" conflicts	Small, frequent merges with minimal conflict
CI validates develop (not production)	CI validates main (which is production)
Release branches for stabilization	main is always stable — deploy on demand
Hotfix branches for emergencies	Revert or fix-forward on main

What Stays the Same

• Pull requests and code review (still required — just on short-lived branches)
• Automated testing (still runs — now on the branch that matters)
• Branch protection rules on main
• All existing CI/CD tooling and pipelines

---

9. Recommendation

!panel(success)
Adopt trunk-based development.
!panel

The evidence is clear and converging from multiple independent sources:

1. DORA research (30,000+ professionals, 7 years) → trunk-based development predicts elite performance
2. Atlassian → now labels Git Flow a "legacy workflow"
3. Vincent Driessen (Git Flow's creator) → recommends against it for CI/CD teams
4. Dave Farley (Continuous Delivery co-author) → Git Flow is fundamentally incompatible with CI
5. Our own experience → long-lived branches cause the exact problems trunk-based development solves

We already have the prerequisites: automated CI pipelines, a culture of code review, and regular deployments. Trunk-based development aligns our branching strategy with our delivery goals.

---

10. References

1. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
2. Driessen, V. (2010, updated 2020). A successful Git branching model. nvie.com.
3. Atlassian. Gitflow Workflow. Atlassian Git Tutorials.
4. Farley, D. (2021). Git Flow Is A Bad Idea. Continuous Delivery YouTube.
5. Humble, J. & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley.
6. DORA Research Program. Google Cloud.
7. Trunk Based Development. trunkbaseddevelopment.com.