Trunk-Based Development sounds simple.
No long-lived branches.
Frequent merges.
Small, incremental changes.
Most teams will tell you:
“Yeah, we basically do trunk-based development.”
In practice, they don’t.
What they usually have is a hybrid that keeps the downsides of feature branches — while pretending to get the benefits of trunk-based development.
I’ve seen this pattern in multiple backend teams. On paper, everything looks modern. In reality, delivery is still slow, pull requests are large, and integration is painful.
So let’s break down what’s actually going on.
The Illusion of Trunk-Based Development
Ask a team how they work, and you’ll often hear something like:
- “We merge to main frequently”
- “We don’t keep branches for too long”
- “We try to keep PRs small”
Sounds good.
But then you look closer:
- PRs are open for 3–5 days
- branches still contain multiple features
- merges are delayed because reviews are slow
- developers are afraid to merge unfinished work
This is not trunk-based development.
This is just shorter feature branches.
What Real Trunk-Based Development Actually Requires
Trunk-based development is not about branches.
It’s about integration frequency and safety.
At its core, it requires:
- merging to main at least daily (ideally multiple times per day)
- keeping changes small enough to review quickly
- having strong safety mechanisms in place
Without these, trunk-based development collapses.
Where Most Teams Break
1. Pull Requests Are Still Too Big
This is the biggest issue.
A developer starts a “small” feature:
- adds endpoint
- updates service
- modifies database
- adds validation
- fixes something unrelated
Now the PR has:
- 15 files changed
- 600+ lines
- multiple concerns
Review slows down. Feedback increases. Merge is delayed.
At that point, it doesn’t matter what you call your workflow —
you’re not doing trunk-based development.
2. Code Reviews Block Integration
In theory:
“We merge frequently”
In reality:
“We merge when the PR gets approved”
That delay is critical.
If reviews take:
- 1 day → integration is delayed
- 2–3 days → conflicts increase
- 5 days → context is lost
Now developers start stacking changes on top of each other.
And suddenly:
- branches live longer
- PRs get bigger
- merges become risky
3. Teams Are Afraid to Merge Incomplete Work
This is subtle but important.
Developers often think:
“I can’t merge this yet — it’s not finished”
So they keep working on the branch.
The problem:
- the longer the branch lives
- the more it diverges
- the harder it is to merge
Trunk-based development requires a different mindset:
You merge incomplete work safely.
The Missing Piece: Feature Flags
Most teams skip this.
And without it, trunk-based development doesn’t work.
Example
You’re building a new payment flow.
Without feature flags:
- you need to finish everything before merging
- you keep a long-lived branch
- integration is delayed
With feature flags:
if (Feature::enabled('new_payment_flow')) {
$this->newFlow();
} else {
$this->oldFlow();
}
Now you can:
- merge partial work
- deploy continuously
- control exposure
Real Example From Practice
I worked with a team that claimed they were doing trunk-based development.
Metrics looked like this:
- average PR size: ~500 lines
- review time: 2–3 days
- merges per developer: ~2 per week
After digging in, the issue was clear:
- developers grouped work “to be efficient”
- reviews were asynchronous and slow
- no feature flags
What changed
We introduced 3 rules:
- PR must be mergeable within the same day
- no PR over ~300 lines (soft limit)
- feature flags for incomplete features
Result after ~3 weeks:
- PR size dropped by ~40%
- review time dropped to hours
- merges increased to multiple per day
- production issues decreased
Not because developers got better.
Because the system changed.
The Hidden Constraint: CI/CD Speed
Here’s something teams often ignore:
You cannot do trunk-based development with slow pipelines.
If your CI takes:
- 20 minutes → friction
- 40 minutes → developers wait
- 60+ minutes → people stop merging frequently
So what happens?
- developers batch changes
- PRs get bigger
- integration slows down
Rule of thumb (2026 reality):
- CI under 10 minutes → good
- under 5 minutes → ideal
Anything above that:
→ you’re actively fighting your workflow
Why This Matters More in 2026
With AI-assisted coding, developers can generate code faster than ever.
That creates a new problem:
volume of changes increases
but review capacity doesn’t
If you don’t enforce:
- small changes
- fast integration
- clear boundaries
your workflow collapses under its own weight.
How to Tell If You’re Actually Doing It
Be honest and check:
- Do you merge to main multiple times per day?
- Are most PRs reviewed within hours, not days?
- Can you safely merge incomplete work?
- Are branches short-lived (hours, not days)?
If not:
→ you’re not doing trunk-based development
Practical Rules You Can Apply Tomorrow
If you want to move closer to real trunk-based development, start here:
1. Limit PR size
Not as a guideline — as a rule.
2. Optimize for review speed
- fewer changes
- clearer intent
- less context switching
3. Introduce feature flags
Without them, you’re stuck.
4. Fix your CI/CD bottlenecks
Speed is not a luxury — it’s a requirement.
5. Stop batching work
Batching feels efficient.
It’s not.
Closing Thought
Trunk-based development is not a branching strategy.
It’s a discipline.
Most teams don’t fail because they don’t understand it.
They fail because they don’t change the constraints that make it possible.
If your:
- PRs are big
- reviews are slow
- CI is slow
- merges are risky
then it doesn’t matter what you call your workflow.
You’re still doing feature-branch development — just with better branding.
And that’s exactly why your delivery still feels slower than it should.
Top comments (0)