I’m a strong advocate for Trunk-Based Development. It’s the idea that the main (or trunk) branch in your source control system is always deployable, and you only ever use a single long-lived branch (as opposed, to say, a develop branch which is eventually promoted to main).

But while there’s no trademark on “Trunk-Based Development”, and therefore no “official” definition, there are two related practices that are often called “Trunk-Based Development”, which can lead to some confusion. I’d like to offer an explanation.

“Strict” TBD

What I call “Strict TBD” (I don’t know what anyone else calls it) is the idea that you literally never create other branches. This means that on your local workstation, you update main, do some work, and push it. If there’s a conflict, because somebody else pushed while you were working, you’ll probably do a pull or a rebase, then push again. End of story.

This approach tends to be advocated by teams who practice ensemble programming (pair or mob programming). In this approach, your CI pipeline runs after merging to main, and if you somehow indavertently break the main branch by unwittingly pushing broken code, then all development on the team stops until main is working again.

“Loose” TBD

I don’t think I’ve ever used the term “Loose TBD” in conversation, but what’s the other alternative to “strict”?

In this approach, you do use feature branches on your local workstation, and you probably use pull requests on the server. You may or may not use the code review feature of your source control management interface. In this scenario, your CI pipeline typically runs on each pull request, before merging to main, which can make it virtually impossible to push unproven code to main.