A tsunami erupted recently when an outreageous post questioned an almost religious practice in software development. Nowadays, at least.
There was a strong rebuttal to an already strong (yet widely accepted) post about the merits of Trunk-Based Development (TBD) versus Feature-Based Development. This exchange was caught by many in the industry, sparking heated debates and polarizing opinions. However, the majority seemed to side with Trunk-Based Development.
This later part is a sign of the time to come, as there seems to be a shift brewing in collaboration processes. This is a healthy thing as the context has shifted quite a bit since the «GitHub way» took over, and it’s natural to question if our tools and methods are still the best fit.
Everybody, start doing trunk based development now!
What happened?
It all started with this fiery reply post:
So, is this blasphemy or not?
What is trunk-based development?
Today, we’d define Trunk-Based Development as a workflow where developers skip long-lived feature branches altogether and push changes directly to the main branch (often called main or master in Git).
Another definition is:
Developers do mainline integration as soon as they have a healthy commit they can share, usually less than a day’s work
This one is from Martin Fowler’s outstanding article regarding source code branches. However, he refers to it as Continuous Integration since this is actually what it was originally!
Should I switch?
You should seriously consider this as a possibility if your team maturity and tooling is up-to-spec for the challenge. It requires strong engineering discipline and a necessary bit of infrastructure.
At a minimum, you’ll need:
- Feature flags – To hide incomplete work in production.
- A robust, up-to-date test suite – Automated tests must be reliable and fast.
- Solid CI/CD pipelines – Frequent merges mean frequent deployments, so automation is key.
It also demands changes in team practices. Going back to Martin Fowler’s article, Trunk-Based Development originated with XP (Extreme Programming), where pair programming was a core practice. Pair programming is almost mandatory in a TBD setup, as it a highly effective way to align work.
Where do you stand?
Both sides of this debate fail to acknowledge one key reality: there are too many different contexts out there for a one-size-fits-all answer.
I really like Daniel’s take as it challenges long-standing practices and forces us to evaluate them on merit rather than tradition. But at the same time, I think he deliberately misses some important caveats.
I also think that some things tainted as weaknesses might not be such. One key factor that helps Trunk-Based Development succeed is pair programming which is great, but also a synchronous practice. Meanwhile, pull request (PR) reviews, while sometimes wasteful and bureaucratic, are asynchronous. This gives teams more flexibility to adapt to changing workloads and time zones.
That said, I firmly believe in the fundamentals: commit and merge to the main branch often and avoid long-lived branches.
These principles matter regardless of your specific branching strategy. Whether your team is all-in on TBD or using a hybrid approach, the key is to minimize integration pain and keep delivery fast and predictable.
Final Thoughts
This debate isn’t going away anytime soon, and that’s a good thing. Challenging the status quo forces us to reevaluate how we work and whether our methods still serve us effectively. I won’t be dropping feature-branches as a tool, but I will certainly have TBD more present from now on.
So.. should you adopt Trunk-Based Development? If your team is ready for the cultural and technical shift, then yes, it’s worth exploring. But like any methodology, it’s a means to an end, not an end in itself.
Juan Saavedra 