Trunk-Based Development vs. GitFlow: Which Source Code Control is Right for You?

Managing source code with a defined method is one vital aspect of implementing effective application development. Today, two strategies for doing this stand above the rest: trunk-based development and GitFlow.

Choosing the proper method for source code control is often dependent upon several factors, such as:

• The maturity of the application
• The maturity of the development team
• The release management process and schedule

In this article, let’s define and compare trunk-based development and GitFlow, look at the factors that drive an organization’s decision between the two. Finally, we’ll discuss the pros and cons of using each of these source code management strategies in various circumstances.

Overview: trunk-based development

Trunk-based development (TBD) is a process for managing source code in which all team members develop in the same branch, aka the “trunk.” In other words, the practice of leveraging long-living feature branches is no more. When necessary, short-living feature branches can be used in order to merge changes into the trunk branch as quickly as possible.

Trunk-based development is centered around two core concepts:

• That development teams should remain in-sync with one another.
• The application should remain in a state that’s always ready for release with the latest features in place.

Trunk-based development requires the scope for individual application modifications to be minimal. This removes much of the need for long-running branches, allowing changes to be integrated regularly (up to multiple times per day) by all developers on the team. To deal with the challenge of building complex features while integrating frequently and maintaining a releasable state, teams using trunk-based development often leverage feature flags to keep functionality that’s under development hidden from the end-user.

(For more dev resources, check out these DevOps conferences & the State of DevOps today.)

Overview: GitFlow

GitFlow is quite different. A legacy Git workflow, GitFlow relies heavily on the utilization of the same feature branches that devs avoid in trunk-based development. At a high level, the process for development using GitFlow looks like this:

1. Developers branch off from a “develop” branch to work on features. These are called feature branches. Feature branches allow developers to work in isolation until their code is in a working state. When the feature branch reaches completion, it’s then merged back into the develop branch.
2. When the application is deemed ready for release, and all the completed work has been merged into the develop branch, a release branch is created off of the develop branch.
3. Once the release branch is deemed bug-free and ready for deployment, the release branch is merged back into the master branch (to be deployed) and the develop branch (ensuring it contains all the bug fixes that may have been made as the release was cleaned up).

(Learn about GitOps, a Git relative that applies DevOps principles to infrastructure management.)

Choosing between TBD and GitFlow

Trunk-based development and GitFlow are different approaches to managing source code for an application. So, how can a team make the correct choice for managing their codebase? Let’s take a look at some of the factors driving an organization’s choice of source code control strategy.

1) The release schedule

The first (and often the most important) factor to consider when deciding on a method for source code management is the release schedule for the application. Can your organization tolerate longer periods of time between releases of the application?

• If the answer is yes, GitFlow could be the better choice.
• If time isn’t an issue for your organization, trunk-based development may be the better option.

Trunk-based development often works best with a flexible schedule that allows developers to work on features in isolation and then merge their work back into the common develop branch only when the new feature is complete and fully functional.

Further, GitFlow would make less sense if your organization is moving towards continuous delivery with frequent application releases. This type of deployment strategy requires the application to be in a state that’s constantly ready to release, with changes being delivered rapidly by the developers. Trunk-based development would allow your organization to achieve this state by keeping the scope of application changes small. When leveraging trunk-based development, the development team can iterate quickly and get batches of application modifications out the door in a time-efficient manner.

2) The maturity of the application

There’s no law against changing the method that you use to manage your source code. In fact, it could make sense to change course as the application matures over time. Let me explain.

There’s often a rapid pace of development behind spinning up a new application. The idea is to get a working application up and running with minimal functionality. So, when working with a relatively new application, it likely makes more sense to employ a strategy that enables an organization to achieve this fast pace. At this stage, trunk-based development makes more sense, because it allows developers to rapidly integrate new functionality into the codebase, thus facilitating the effort to get the application off the ground and into an established state.

However, it’s likely that the application will be in production with all the major functionality in working order in a matter of months. At this point, an organization is usually less concerned with the speed of development and more concerned with having a greater level of control over the changes introduced into the codebase. Here, GitFlow makes more sense because it enables just this type of oversight.

Obviously, it can be difficult to keep tabs on all application changes when multiple developers are committing multiple times per day to the shared branch (as is the case in trunk-based development). With GitFlow, developers work in isolation for a while before merging their feature back into the shared branch.

This GitFlow source code control strategy can lead to fewer changesets introduced to the shared branch, which allows for easier identification of the changes that have been made and who made them. Greater transparency helps facilitate quality control processes such as code reviews and makes it less likely for modifications that detract from application viability to slip through the cracks.

3) The maturity of the development team

In keeping with the theme of the previous point, GitFlow provides a model that enables senior development staff to have greater visibility into the application changes made by other team members. With changes integrated into the shared branch at a slower pace, there’s greater opportunity for developers in positions of leadership to ensure that application changes are made in accordance with the guidelines set by the organization.

• If the development team contains a lot of entry-level developers, then it’s likely that such opportunities for review and mentoring will be considered necessary by those in charge.
• If you have a small development team with high levels of experience across the board, such oversight is likely not required, and thus, trunk-based development can be safely employed.

A case-by-case basis

Choosing the right method for managing source code should be done on a case-by-case basis, there’s no one-size-fits-all. Making a decision that will result in efficient, high-quality development requires taking a hard look at various aspects of the organization. These include the state of the application, the experience level of the development team and the desired frequency for releasing changes. When these aspects are analyzed properly, the choice will seem obvious.

What is Splunk?

This article was written by Scott Fitzpatrick, who has years of experience as a software developer. He has worked with many languages, including Java, ColdFusion, HTML/CSS, JavaScript and SQL. Scott is a regular contributor at Fixate IO.

This posting does not necessarily represent Splunk's position, strategies or opinion.