Trunk-Based Development, a radical solution to “merge hell”

GitFlow or the Joys of Merge Hell

GitFlow is often presented as the gold standard for collaborative work. This model has its merits, but like any tool, it must be used wisely. While GitFlow is a must in open-source, it isn’t designed for SaaS (Software as a Service), where versioning isn’t visible to the user. This is by its creator’s own admission: he apparently got tired of being booed.

And besides, the GitFlow model requires discipline. I’ve seen too many Git histories that look like the train switches at Gare du Nord or the incestuous family tree of the kings of France 👑

The problem with GitFlow is “merge hell,” which you’ll face sooner or later if you insist on creating long-lived feature branches: endless conflicts and automated tests that are hopelessly red. “Merge hell” is the antithesis of continuous integration.

Trunk-Based Development, a radical solution

Trunk-Based Development, on the other hand, involves working on a single branch, called the “trunk” or “main.” Simple, brutal, and beautiful. Confusing, to say the least. And yes, it works: Google, among others, works this way.

To take this exercise to its logical conclusion and be “extreme” as we like to be, here are two suggestions:

1. Don’t create Pull Requests (PRs); opt for pair programming instead. If you really want to create PRs, you’ll need to create feature branches, but they should have a short lifespan (<1 day). Or make sure to perform very frequent rebases.

2. Don’t stop there; go all the way to continuous deployment: every commit goes into production. Not only is this useful in and of itself, but it will also save you from having to create a branch for a bug fix (cherry-pick from main).

Don’t go in with your guard down

Don’t jump into this adventure simply because you think it’s a good idea; you might end up disappointed. There are, in fact, two major prerequisites:

• Automating tests: since you share your code very frequently with the team, several times or even dozens of times a day, and every commit may go to production, you can’t rely on manual regression testing. Automated tests of all kinds are your friends; they’re the foundation of continuous integration anyway.

• Breaking your work down into fine-grained chunks so you can push your production code more frequently to main. Ideally, you should break it down from a business perspective into user stories, because that way you frequently deliver value to users and get user feedback at the same time. So avoid the infamous back-end / front-end division; there’s usually a better way.

On this second topic, also consider feature toggles (a.k.a. feature flags), which let you disable a feature in production until its development is complete. Probably best viewed as a last resort, but a very useful one nonetheless.

Of course, you have to admit that at first, Trunk-Based Development “is a bit rough…” It might be better to try it out on your own with a side project, just to get comfortable with the idea before bringing it up with your friends. Beyond that, while the approach may seem inconceivable at first glance to many developers, experience shows that trying it out often changes their minds.