Introduction

This is quite exciting for me: With GitLab hosting, This Friday (21st August, 2020) I am going to talk about the Trunk-Based Development and Branch By Abstraction book that I have out on Leanpub. I’m expecting some hard questions on behalf of enterprises and startups. Jordi Mon is gathering those now.

Register for the event on the GitLab Version Control & Collaboration page - scroll half way down.

One of the registrants will get a free copy of the book. Signed too, somehow, even though it is elecronic!

One line summary

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.

* master, in Git nomenclature

Shared branches off mainline/master/trunk are bad at any release cadence:

Trunk-Based Development For Smaller Teams:

Scaled Trunk-Based Development:

Elaboration, Claims and Caveats

Trunk-Based Development is a key enabler of Continuous Integration and by extension Continuous Delivery. When individuals on a team are committing their changes to the trunk multiple times a day it becomes easy to satisfy the core requirement of Continuous Integration that all team members commit to trunk at least once every 24 hours. This ensures the codebase is always releasable on demand and helps to make Continuous Delivery a reality.

The dividing line between small team Trunk-Based Development and scaled Trunk-Based Development is a subject to team size and commit rate consideration. The precise moment a dev team is no longer “small” and has transitioned to “scaled” is subject to practitioner debate. Regardless, teams perform a full “pre integrate” build (compile, unit tests, integration tests) on their dev workstations before committing/pushing the for others (or bots) to see.

Claims

You should do Trunk-Based Development instead of GitFlow and other branching models that feature multiple long-running branches

You can either do a direct to trunk commit/push (v small teams) or a Pull-Request workflow as long as those feature branches are short-lived and the product of a single person.

Caveats

History

Trunk-Based Development is not a new branching model. The word ‘trunk’ is referent to the concept of a growing tree, where the fattest and longest span is the trunk, not the branches that radiate from it and are of more limited length.

It has been a lesser known branching model of choice since the mid-nineties and considered tactically since the eighties. The largest of development organizations, like Google (as mentioned) and Facebook practice it at scale.

Over 30 years different advances to source-control technologies and related tools/techniques have made Trunk-Based Development more (and occasionally less) prevalent, but it has been a branching model that many have stuck with through the years.

This site