This post was written by a guest author.

When you have a lot of software developers working on the same project, keeping track of individual changes and previous versions is crucial, especially when it helps prevent conflicts that slow the development and deployment process. For most development teams across the world, Git is the system of choice for organizing files and versions of software. 

From the onset of a project, your team should select a development strategy and ensure that all team members apply it consistently throughout their workflow. Choosing the right strategy depends on a few things, including team size, the complexity of the software you’re developing, and other tools you’re already using. You should also consider how your team prefers to work together, and the expertise and experience of individual team members. 

This article will highlight Trunk Based Development, including benefits and best practices, as well as some popular Git branching strategies: Gitflow, GitHub flow, and GitLab flow. 

• What is Trunk Based Development
• Benefits of Trunk Based Development
• The Cons of Trunk Based Development
• Trunk Based Development Best Practices
• Popular Git Branching Strategies
• Gitflow vs Trunk Based Development 

What is Trunk Based Development?

Trunk Based Development is distinctly different in approach to the most popular Git branching strategies. Rather than relying on feature branches, Trunk Based Development has each developer work locally and independently on their project, and then merge their changes back into the main branch (the trunk) at least once a day. Merges must occur whether or not feature changes or additions are complete.

Patrick Lee Scott summarizes how to approach Trunk Based Development with Git in an article for HackerNoon:

“…we’ll need to approach things a bit differently than you’re probably used to. We’ll still want to tie some actions to commits, but not so many different concepts – we only want to do things that are related to the codebase we are working on. Instead, we can limit that action to releasing a new versioned artifact of the project we are working on.”   

In another article, Ben Morris explains: 

“Trunk based development is more than just a branching strategy. It’s a cluster of techniques that can help to enable more efficient development. 

Teams use branching by abstraction to separate work on large-scale features. Abstraction layers isolate work in progress and allow multiple implementations of functionality to exist in the same code base. A system can be released from a trunk safely despite containing multiple incomplete features.” 

Benefits of Trunk Based Development

Trunk based development strategies are less complex than traditional Git branching strategies as they typically involve fewer branches and less risk of Git merge conflicts. Trunk Based Development is also uniquely well-suited for use in CI/CD methodologies because the trunk is constantly deployable. 

Regular updates provide greater visibility into the status of project changes for the entire team. As a result, teams can identify and resolve potential merge issues more quickly. Compared to Gitflow, where long periods can elapse between merges, increasing the chances of conflicts, trunk based development limits the risks of conflicts. With trunk based development, the descent into merge hell is far less likely.

Collaboration occurs at the trunk rather than on individual feature branches in trunk based development. However, team members must constantly collaborate to prevent issues from infecting the trunk. Overall, collaboration levels are required to be high, and all team members must be constantly pushing together towards the next goal.

GitKraken Client was designed with team collaboration in mind, offering less context-switching, better communications, and seamless processes for whatever workflow you prefer.

Because of its agile nature, Trunk Based Development can also be very useful in today’s container and microservice-heavy development environments.

The Cons of Trunk Based Development

Of course, Trunk Based Development is not without its issues. Foundationally, trunk based development is more complicated than more traditional Git branching strategies, and thus requires more advanced development skills.  

As Ben Morris explains in his article, Why Trunk Based Development Isn’t for Everybody: 

“Although Trunk Based Development can reduce merging conflicts, it does not necessarily reduce complexity of managing concurrent feature development. In a sense, you’re just redistributing some of this complexity downstream to other processes, such as the code design and application configuring.”  

Younger developers are likely to be less confident using trunk based development, as changes go directly into the trunk rather than intermediate stages as in other Git-based strategies. And there is a good reason for this concern. Problems injected into the trunk by inexperienced developers can cause major deployment issues. Therefore, Trunk Based Development strategies are best when you have smaller teams of experienced developers.

Trunk based development is also less capable of tracking individual changes. Whereas Gitflow is highly organized, using individual branches for each feature, trunk-based strategies dump all changes into the main branch no matter their state. It can be easier to lose track of the individual pieces. 

You can level up your team’s Git experience with GitKraken Client, a tool that enables junior developers and experts alike to increase their productivity, including Learn Git resources will help beginners increase their knowledge at a fast pace.

Trunk Based Development Best Practices

As mentioned previously, a smaller team with advanced development skills will have a better chance of succeeding with Trunk Based Development strategies. 

You will also want to ensure you have a codebase that can support feature abstractions, and that you are prepared with a solution for feature flags. 

Finally, invest in a continuous build and test infrastructure and streamlined processes for reviews and releases that can accommodate a high rate of commits.

Popular Git Branching Strategies

When compared to Trunk Based Development, the following Git branching strategies are workflows that make having multiple parallel development paths for an application simpler and less error-prone. More straightforward branching strategies in Git can help inform individual developers how to integrate their changes into the main production version of the code.

Well-selected Git branching strategies offer development teams many potential benefits, including:

• Streamlining parallel development
• Promoting efficient team collaboration
• Providing clear-cut development workflows for integrating changes into production code
• Minimizing Git merge conflicts
• Limiting the introduction of bugs into the production code
• Providing a streamlined roadmap for new releases

The most popular Git branching strategies include: Gitflow, GitHub flow, and GitLab flow.

Gitflow

Gitflow has historically been one of the most popular branching strategies for teams using Git. The strategy uses five different branch types in total: two primary branches – the main and develop branches – along with three special purpose branches such as feature, release, and hotfix. The main branch in Gitflow uses tags to identify specific production versions (0.1, 0.2, 1.0 as shown in the diagram below). Develop branches are cloned from a tagged main branch version. 

Using Gitflow, many developers can work in parallel, collaborating within the feature branches before the release of new candidates. And because Gitflow uses a separate sandboxed staging area for releases, it can help development teams ensure that only verified functionality makes it to production. Separate release branches also allow teams to easily integrate security-by-design principles into the development process.

Special purpose branches are created from the develop branch, and multiple special purpose branches can exist simultaneously. While the main and develop branches are perpetual, feature branches typically only exist as long as necessary to complete a particular task, which can be days, weeks, or even months. 

Teams work directly together in the feature branches. As they complete the development of a feature, they merge it back into the develop branch. There is no set schedule for merging new features – merges occur as needed.

In addition to feature branches, developers can work with hotfix branches to quickly resolve issues in the production code. Unlike feature branches, hotfix branches extend from the main branch. However, developers must remember to merge completed hotfixes into both the main and develop branches.

Development teams may clone a release branch from the develop branch. The release branch serves as a testing and QA sandbox for new release candidates. As with hotfix branches, finalized modifications in the release branch must be merged into both the main and develop branches. 

Vincent Dreissen, the creator of Gitflow, created a useful summary overview graphic of the various Gitflow branches and how they relate to each other: 

Gitflow vs Trunk Based Development

With its highly organized, well-defined, and well-segregated structure, Gitflow makes it easy to know what’s going on in a project at any given time. However, the addition of numerous branches increases the risk of merging conflicts. And the larger the team, the larger the risk of introducing problems into the main codebase. 

Because the Gitflow strategy requires a developer to perform many different commits before code goes into production, project history can become difficult to analyze. Tracking errors back through the complex web of branches and commits can be time-consuming and frustrating. Indeed, even though Gitflow aims to speed development, if individual developers lack an understanding of how to properly implement the strategy into their workflow, success will be unlikely. 

If you team does need more visibility into their project history, a robust but easy-to-use Git GUI like GitKraken Client can make a huge difference for developers of every skill level. Setting up Gitflow in GitKraken Client is extremely easy and intuitive, requiring just 3 steps.

The complex nature of Gitflow and lack of defined times for commits to the main branch also make it unsuitable when teams want to implement continuous integration/continuous delivery (CI/CD) workflows. By its very nature, continuous integration is predicated on regular, periodic merges of code changes to the master branch. On the other hand, if your project allows for longer periods between deployments, Gitflow can be an excellent choice.

Similarly, continuous delivery requires the ability to go to production immediately. In Gitflow, however, developers must create a release branch, merge it into the main and develop branches, and tag the new production version in the main branch before changes get to production. Gitflow really encourages more of a discontinuous delivery process than continuous.

GitHub Flow

GitHub flow is a simplified version of Gitflow that eliminates the develop and release branches. Instead, feature branches come directly from the main branch. 

With this strategy, developers commit changes to the feature branch and test them there as well. Only after making a go decision do developers merge the feature branch to the main branch.

Because GitHub flow lacks the intermediate branches of Gitflow, the history is easier to follow. And unlike Gitflow, GitHub flow integrates easily into CI/CD pipelines.

One downside of GitHub flow is that failure to adequately test feature changes before merging them into the main branch can lead to buggy and unstable production versions.

Because it’s lightweight and faster than other Git branching strategies, GitHub flow works well for small teams applying agile development principles. As teams increase in size, however, GitHub flow loses its beneficial qualities.

GitLab Flow

Another simplified version of Gitflow, GitLab flow uses a pre-production branch for testing changes before merging them back to the main branch and going to production. GitLab flow focuses on issue tracking, building useful histories as new features are merged into the main branch. And as with GitHub flow, GitLab flow is more viable when working with CI/CD.

Is Trunk Based Development Right for You?

Trunk based development and other branching strategies each have areas where they excel and where they fall behind. Fortunately, if your needs or circumstances change during a project, it is possible to switch from one strategy to another.

Keeping track of changes and versions throughout the software development lifecycle is a crucial but less than simple task.  Ultimately, trunk based development and popular Git branching strategies should provide developers with the tools they need to ensure robust, stable production versions while allowing them to deploy changes as frequently as desired. 

As with most tools, there is no “one size fits all solution.” Consider the composition of your development team and the needs of each specific project to decide which path is right for you. And, if you don’t succeed at first, shift to another approach. It’s really as simple as that.