A case for trunk-based development
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
master
, ormain
in git). - 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.