Trunk Based Development vs Gitflow

The use of version control has become ubiquitous in modern software development, with Git overwhelming being the tool of choice for most organisations. When using version control, it's critical to choose a workflow that best suits the goal of the team, with the primary tradeoff's being efficiency and ease of use balanced against safety (quality and approval gates) and flexibility. The two most common approaches that have emerged are Gitflow and trunk based development, which are diametrically opposed in this tradeoff.

What is the Gitflow Workflow?

The key premise of Gitflow is that each commit to your primary branch represents a release and a secondary branch, develop, is used for ongoing development. New features are built on feature branches and then reviewed and merged into the development branch. When changes are ready to be released, a release branch is created, and when the release is complete that branch is merged into the primary branch.

The concept was first published and made popular by Vincent Driessent at nvie, however he now believes it no longer aligns with modern development as more companies shift to continuous delivery. As such, Gitflow is most effective for teams that follow an extensive release management process that prevents continuous deployment, particularly if multiple stakeholders need to approve a release before it goes live. In such an environment, the release branch acts as a gatekeeper to facilitate the process while enabling developers to keep merging changes into the development branch. Additionally, Gitflow supports hotfixing releases without requiring approval for changes made since the last release.

What is Trunk Based Development?

In trunk based development, developers merge small, frequent updates to the primary or "trunk" branch. Idiomatic trunk based development has developers committing directly to the primary branch, however it is common for teams to use short lived feature branches to support code reviews and automated checks prior to merging, this variant can sometimes be referred to as scaled trunk based development or feature branch workflow. Releases are done directly from the primary branch and since you are already deploying on all commits to the primary branch, fixes to deployed code is treated no different from any other code change.

This workflow is ideal for teams that utilise continuous deployment. Having two primary branches, as in Gitflow, would be unnecessary since they would essentially mirror each other, and so teams would benefit from this simpler workflow.

TL;DR

This article discusses two common approaches to using version control in software development - Gitflow and trunk based development. Gitflow is more suitable for extensive release management processes that involve multiple stakeholders, whereas trunk based development ist ideal for continuous deployment, and so ultimately which workflow is most suited for your project will depend on the team's goals and tradeoffs between efficiency, ease of use, safety, and flexibility.