Source Code Control: Trunk-Based Development vs. GitFlow

160 VIEWS

Managing source code with a defined method is one vital aspect of implementing an effective organizational application development lifecycle. Today, there are two popular strategies for doing this that 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 and the release management process and schedule. In this post, I will define and compare trunk-based development and GitFlow, as well as describe the factors that drive an organization’s decision between the two. In addition, I will discuss the pros and cons of using each of these source code management strategies in various circumstances.

Defining the candidates

Trunk-based development

Trunk-based development is a process for managing source code in which all team members develop in the same branch, which is often referred to as the “trunk.” In other words, with trunk-based development, 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 the concept that development teams should remain in-sync with one another and 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.

GitFlow

GitFlow, on the other hand, is quite different. GitFlow relies heavily on the utilization of the same feature branches that are specifically avoided in trunk-based development. At a high level, the process for development using GitFlow looks like this:

Developers branch off of a “develop” branch to work on features. Naturally, 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.

When the application is deemed ready for release, and all of the completed work has been merged into the develop branch, a release branch is created off of the develop branch.

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

Which strategy is right for your team?

Trunk-based development and GitFlow represent two very 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, then GitFlow could be the better choice. If time isn’t an issue for your organization, then trunk-based development may be the better option. Oftentimes, trunk-based development 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.

In addition, 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. And, 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 being introduced into the codebase. Here, GitFlow makes more sense, because it enables just this type of oversight. Obviously, it can be very 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 being 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 being made by other team members. With changes being 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 being 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. On the other hand, 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 likely seem obvious.


Scott Fitzpatrick has over 5 years of experience as a software developer. He has worked with many languages, including Java, ColdFusion, HTML/CSS, JavaScript and SQL.


Discussion

Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *

Menu