A Guide to Git with Trunk Based Development

Learn the mindset and process behind Trunk Based Development

Through my consulting business, I equip technology organizations with the latest and greatest in DevOps tooling to increase the velocity of their development teams.

Part of this means abandoning outdated workflows like “GitFlow” and replacing them with more streamlined processes — Trunk Based Development and Continuous Deployment.

We’ll get more into “Trunk Based Development” soon — but it’s important for this conversation to define what “trunk” is, as I’ve seen this misused as well.

The “trunk” is the main or master branch of your repository. Trunk is a constant. In trunk based development, you either commit to the trunk branch, or make branches and pull requests against the trunk branch. There are no long lived alternative branches to merge against such as development.

I’ve seen teams create a new branch and call it the new “trunk” every few weeks. Although I applaud the effort, it was missing the mark by quite a lot.

We’ll get more into what this process looks like end-to-end later on… First, let me spend a minute backing up my claims of GitFlow being outdated, and explain the goals of moving to a different approach.