If you’ve ever been stuck in merge hell, staring at a pull request that looks more like a season finale cliffhanger than a clean diff, you know the pain of long-lived branches. It’s the dark side of Git. A better approach is trunk-based development, where you work with many short-lived branches and maintain a main branch that is always deployable. As any Mandalorian will tell you: “This is the way.”
Why Trunk-Based Development? 🤔
Trunk-Based Development (TBD) is the practice of keeping your main branch as the single source of truth, with developers committing small, frequent changes directly to it or preferably through very short-lived branches. These short-lived branches are key because they allow for pull requests and peer reviews without introducing the complexity and risk of long-lived branches. Frequent integration reduces merge conflicts, keeps the mainline healthy, and ensures that code reviews happen while the context is still fresh for both author and reviewer.
The book Accelerate and the annual State of DevOps Report make this clear: elite-performing teams practice TBD. In fact, Accelerate explicitly calls out that teams who integrate into trunk at least daily have higher software delivery performance and lower change failure rates.
Martin Fowler reinforces this principle in his article Patterns for Managing Source Code Branches:
“The mainline should be healthy and always ready to be deployed into production with minimal effort.”
This is the essence of TBD—keeping the trunk deployable at all times.
Why Not the Alternatives? 🚫🌵
There are many branching models out there—Gitflow, GitHub Flow, Mainline, Cascade—but each introduces complexity that slows delivery and increases risk. These models create bottlenecks, increase merge conflicts, and make continuous delivery harder. TBD avoids these pitfalls by keeping the codebase always releasable and reducing integration pain.
In addition to explaining trunk-based development, TrunkBasedDevelopment.com examines these alternative models and highlights the specific problems they create, reinforcing why TBD is the preferred approach for high-performing teams.
Addressing Gitflow, because many people have asked me about why it shouldn't be used: Back in 2010, Vincent Driessen introduced A Successful Git Branching Model, and it was a game-changer—for its time. It worked well for packaged software with infrequent releases. But not for modern web apps and services deploying multiple times a week or day. Driessen's edited note at the top of the post agrees with Gitflow no longer being a good fit for many situations. Gitflow is like wearing Mandalorian armor to a beach party: impressive, but wildly impractical.
ThoughtWorks’ Technology Radar warns against long-lived branches. They slow feedback loops, increase merge conflicts, and create risk. In short: they’re the Sarlacc pit of software delivery.
This Is the Way
TBD aligns perfectly with continuous delivery principles:
- Small,
frequent commits → Easier to review, easier to roll back.
- Fast
feedback → Bugs surface quickly, not weeks later.
- Reduced
merge conflicts → Because you’re not hoarding changes like a Jawa
with spare parts.
And yes, feature flags are your jetpack here. They let you
deploy incomplete features safely, without branching off into the Outer Rim.
How to Start Walking the Way
- Short-lived
branches only (think hours and days, not weeks, and never months).
- Automate
everything: CI/CD pipelines, tests, deployments.
- Feature
flags over feature branches.
- Cultural
shift: Encourage collaboration and trust. Psychological safety matters
when you’re committing to trunk daily.
In the words of the Armorer: ⚔️
"When one chooses to walk the Way of the Mandalore, you are both hunter and prey."
When you choose Trunk-Based Development, you’re both developer and deployer.
It’s not always easy, but it leads to stronger, more resilient teams and
systems.
This is the way! 🛡️✨
References:
- ThoughtWorks. Long-lived branches with Gitflow
- Forsgren, N., Humble, J., & Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution
- DORA. Trunk-Based Development Capability
- Fowler, M. Patterns for Managing Source Code Branches
- Trunk-Based Development - Introduction
- Trunk-Based Development - Alternative Branching Models
