Are feature branches bad, per se?

Trunk-Based Development is the standard everyone commercial software project should aim for.

I got a lovely question on LinkedIn this morning:

Are feature branches bad per se? Is Trunk-based development always the way to go? I know you have a unique and refreshing opinion on this. 💪

Here’s how I responded:

Feature branches make great sense in an intentionally slow-moving environment where you don’t trust the people making changes, so you need a mandatory review and vetting process. i.e. open-source software.

Nominal feature branches can make sense in a high-trust, fast-moving environment where you need to run automated tests in isolation (not on trunk) before merging. But the key here is that they are nominally feature branches. The ideal here is still trunk-based development, with an extra automated test/quality gate before truly merging to main.

IMO, Trunk-Based Development is the standard everyone commercial software project should aim for. Not all will arrive, but even just inching closer can have big payoffs.

What do you think? Are you aware of a situation where feature branches are actually superior to trunk-based development?

Share this