A case for trunk-based development
March 10, 2021
Yesterday I explained that GitFlow is anti-agile, but what’s the better alternative?
Trunk-based development is the core method I advocate. The one-line summary is:
A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’*, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.
- main or master, in Git nomenclature
There are a number of variations I use in specific situations, but the core practices of meaningful trunk-based development are:
- There is a single immortal branch: mainline (often called
- The mainline branch must always be release ready.
- All coding happens in short-lived feature branches, which are frequently merged into mainline, then deleted.
This approach offers many benefits which I won’t get into today, but one is that it’s a natural fit for real continuous integration.
GitFlow is anti-agile
GitFlow is an error-prone waterfall process. It makes continuous integration and continuous deployment impossible. Just avoid it.
The Technologist Podcast #4: Continuous Delivery, DevOps, Go
Coach Denis interviews me about my mission to bring enterprise-class software delivery to small teams with small budgets.
Long-lived branches discourage refactoring
Every refactoring tends to entangle all the other functional changes together, which makes it even harder to advance changes to the production branch.