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, or main 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.