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 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.

Share this

Related Content

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.