A Case for Trunk-Based Development

Why do we hold onto our code for so long before showing it to each other?

Most teams I’ve worked with (and most setups I’ve used) default to some version of: Create a feature branch → Work for a few days → Push a PR → Wait for review → Hope it merges clean.

It feels normal. Professional, even. But after watching a video by Dave Farley, I started wondering whether that approach, however polished, is fundamentally at odds with what continuous integration was meant to be.

And if we’re honest, the cost of holding onto code is real:

• Merge conflicts that eat hours
• Integration bugs that don’t show up until late
• Review cycles that turn into backlogs
• Features that go stale before they ship

So here’s my proposal:

What if we stopped working in isolation and started working in the open, every day? What if the default wasn’t to hide changes, but to integrate them immediately?

A Simpler Model, Hiding Less

Enter: Trunk-Based Development (TBD).

The idea is disarmingly simple:

• Everyone commits to a shared main (or trunk) branch
• If you do branch, the branches live for a few hours, max a day
• You commit often (multiple times a day, ideally)
• You use feature flags, dark launching, or branch by abstraction to hide incomplete features, not separate them

The goal isn’t just faster merging, it’s always working on the same “truth” of the codebase, together.

You shrink the distance between your work and everyone else’s.

You don’t wait to be “done” to integrate. You integrate to help get to “done.”

Why It’s Worth Considering (Even If It Feels Radical)

I haven’t rolled out TBD on a team yet, but I want to. Here’s why it’s compelling to me:

🧩 It removes the “two truths” problem

Every branch is a fork in reality. Testing, debugging, and merging all become harder when you’re working on different timelines. TBD says: stop forking reality.

⚡ It tightens feedback loops

If your changes break something, you know immediately. If they work well, others can build on them, right now.

🤝 It encourages better engineering habits

Small, testable commits. Stronger CI/CD. Less cowboy coding. More collaboration. This model nudges you toward sustainable speed.

🌱 It helps you grow as a developer

When you ship partial features behind flags and test unfinished ideas in production (safely), you start thinking more modularly. You work in smaller steps. You get better at decoupling.

So, How Do You Work Without Branches?

We’d need some process guardrails to make this safe and practical. Based on what I’ve learned, here’s what adopting TBD might look like:

✅ Daily—or more frequent—commits to main

Work in small, composable chunks. A few lines of logic. A tiny refactor. A test case. Ship that. Move on.

✅ Feature flags everywhere

Use toggles to control whether a feature is active, not whether the code exists. That means you can commit unfinished work without affecting users.

✅ Strong CI/CD pipelines

If commits go straight to main, your tests better catch regressions fast. Ideally, your test suite gives you high confidence on every push.

✅ Dark launching and branch by abstraction

Need to deploy backend logic without exposing a UI? Do it. Want to refactor a critical path gradually? Abstract it, then replace it behind the scenes.

Why This Isn’t Just About Speed

One of the most surprising things I took away from Dave Farley’s talk was that trunk-based development isn’t just about faster releases. It’s about trust.

Trust that your teammates won’t break things carelessly. Trust that your process can catch bugs early. Trust that your code doesn’t have to be perfect before it’s shared.

It’s not about being reckless. It’s about choosing visibility over isolation. And when you do that, something strange happens: People talk more. Teams align better. Features ship more predictably.

The Trade-Off

Adopting this would mean letting go of “I’ll push when I’m done.” It would mean embracing partial work in main. It would mean making integration a habit, not a milestone.

But the payoff? No more last-minute merges. No more “Oh wait, you changed that too?” No more testing code that will never actually ship.

Final Thought

Git made branching feel cheap. But integration costs? Those are still high, especially when you do them late.

TBD flips the script: it makes integration cheap and isolation costly.

That shift, mental, technical, and cultural, is what makes it worth exploring.

If you’re building something fast-moving and collaborative, I think this approach deserves more attention. I’m still learning, still poking holes, but the direction feels right.

And maybe, just maybe, it’s time we stop treating integration as the thing we do at the end, and start treating it as the thing we do all the time.