Git Branching Strategies Vs. Trunk-Based Development

When your software development team members are seeking to work together on a Git coding project, it’s important to make sure all team members are on the same page. This means they should have the same goals for the project, but it also means they should use the same branching strategies.

Selecting the branching strategy you want to use often comes down to Git branching strategies vs. trunk-based development. We’ll discuss the pros and cons of each of these strategies and help you determine which one will work better for your particular situation.

Our Recommendation = Use Trunk-Based Development

Trunk-based development involves a strategy where all the developers on your team will make their changes within a shared trunk (or main branch). Your developers are able to work in their local repositories throughout the day, but they must then integrate their code with the shared trunk at least once per day.

This gives all your team members the ability to regularly see the changes that others are making to the code. You then have the ability to make comments on the work that other team members are doing, enhancing collaboration. 

This strategy keeps the project moving forward, as the collaboration among your team members is constant. You don’t have to worry about some team members moving too far away from the core of the project goals, which could happen if they work on their local repository for several days before integrating their code. This could waste time and effort.

Benefits of Using Trunk-Based Development

• Collaboration: The process of having you and your team integrate your work into the main branch on a daily basis forces a higher level of collaboration. Your team members have to be on the same page to make this type of strategy work, and regular collaboration ensures this.
• Quick and nimble: Because you will be implementing changes on a daily basis with trunk-based development, you will think about your projects differently. You will focus on the small steps when building the project, which allows your team to be as nimble as possible.
• Continuous integration: If you want your team to focus on continuous integration (CI) in the workflow, trunk-based development meshes perfectly with CI. The two share a lot of traits. Other Git branching strategies really don’t support CI as well or at all.
• Fewer merge conflicts: As developers implement their changes to the main branch using trunk-based development, the chance of having merge conflicts goes down. Merge conflicts are far more common in other Git branching strategies. Someone has to manually intervene to fix merge conflicts, costing your team time.

Switching Over to Trunk-Based Development

Your development team may start with the simplistic GitHub Flow Git branching strategy because you initially need a simple strategy for a small team. However, you may find that as the project expands and as your team grows, GitHub Flow no longer fits your needs. 

One of the best things about trunk-based development is that you can jump from a Git branching strategy into trunk-based development at any time. This strategy is adaptable, depending on the project’s current needs.

The ultimate goal of deploying either trunk-based development or Git branching strategies is to make it easier for your team to operate at a higher productivity level. You don’t have to only rely on one type of strategy from beginning to end. Switching between development strategies to match the current needs your team and your project have is perfectly acceptable.

When to Use Git Branching Strategies Instead

Although there are a few other options, by far, the two most popular Git branching strategies are Git Flow and GitHub Flow.

Benefits of Using Git Flow

Git Flow initially appeared in 2010 as a means of giving those new to Git a way to make use of Git’s branching model and to become productive quickly. However, its use of multiple branches increases the chances of merge conflicts, which is the primary reason trunk-based development is now a more popular strategy. Git Flow still has some advantages for certain teams, though.

• Teams working in parallel: Your team members can work in parallel, meaning that any new coding remains separate from finished coding until you are absolutely ready to merge the two. There is no daily requirement to merge code with the main branch.
• Teams that collaborate heavily: By starting work in the feature branch in Git Flow, multiple developers can collaborate on the coding easily, as long as they have access to the feature branch. In trunk-based development, coders tend to work on their own until they upload to the main branch, which is where the collaboration begins.

Benefits of Using GitHub Flow

GitHub developed GitHub Flow as an alternative Git branching strategy option to Git Flow. It has particular benefits for the following teams:

• Teams that need to respond quickly to issues: Because of the regular deployment strategy behind GitHub Flow, your development team is able to quickly fix problems and address issues. 
• Teams creating or working with web applications: GitHub Flow’s focus on regular deployment and streamlined branching strategies makes it ideal to use for creating web applications and web services software. Small teams can quickly and efficiently create web applications, releasing the code in a hurry and then making any changes or updates just as efficiently.

Simplicity of Merging Changes

Winner = Trunk-based development

One significant headache that can occur for software development teams using Git is when a large coding change merges to the main branch. The merge process from one developer could cause significant conflicts with the changes from other developers, leading to “merge hell.”

Trunk-based development greatly reduces the chances of experiencing merge hell, thanks to the smaller, but frequent, changes that are part of this strategy. By forcing your developers to merge the changes from their local repositories every day, any problems with merging typically are minimal. This allows your team to work through the problems faster, keeping the project on track and having the code ready for a release at almost any point in the process.

Organizing the Developers’ Work

Winner = Git branching strategies

One of the biggest advantages of using Git branching strategies is the ability to make use of multiple branches in parallel without having to merge the changes to the main branch. Because developers can work on their own branches without having a daily deadline to merge their code, they can keep their work separate and organized until they have it completely ready.

Your development team also can use these strategies to create branches that focus on specific tasks. It may be easier to complete a specific job when you can focus on a separate branch without a strict time deadline. (Git Flow offers far better success with organizing the separate branches than GitHub Flow.)

With trunk-based development, developers must focus on all the work entering the main branch on a daily basis. Sometimes, this causes individual jobs to become lost in the shuffle of the changes made to the main branch.

However, your team may end up having trouble managing the project when too many separate branches become involved in the project. When it’s time to merge the separate branches into the main branch with Git Flow, it sometimes can become a highly complex process. It also can be difficult to go back and track any specific point in which errors to the coding project occurred when using this strategy. 

Short Production Cycles

Winner = Git branching strategies

When you need a branching strategy that allows for short production cycles, so you can oversee releases on a frequent basis, the GitHub Flow Git branching strategy typically will deliver the best results. This strategy allows the changes to occur quickly and deployment of the changes to occur continuously. This shortens the production cycle, perhaps even allowing for several releases in a day.

With trunk-based development, the developers work primarily in their local repositories, which naturally slows the process a little bit. The trunk-based development strategy will lead to a slightly longer production cycle than what GitHub Flow can produce, although trunk-based development still can deliver nimble results.

CI/CD Development

Winner = Trunk-based development

When using CI/CD development processes to create your code, trunk-based development is the easy winner in this comparison. CI/CD is a modern strategy for creating and delivering code efficiently and safely.

• CI is a type of software development that allows for quick and frequent changes in code. Through CI, your team is able to easily verify that code changes are reliable. 
• CD (or continuous delivery/deployment) is the process by which the delivery of the coding project occurs. The CD development process allows for a faster release of new features.

Through CI/CD, your development team can create, test, deliver, and release code in an efficient manner. It allows for introducing innovations at a fast pace too.

When you want to make use of CI/CD, the trunk-based development strategy is the best option. Because your development team will be making frequent changes to the main branch, this closely matches the development process found with CI. The trunk-based development strategy then allows for the release of your new features quickly (as occurs with CD).

Trunk-based development and CI/CD have a close alignment, meaning that if you want to follow the CI/CD development process, trunk-based development is a more natural selection than Git branching strategies. This close alignment means that CI is always at the forefront of your team’s efforts and focus when making use of the trunk-based development strategy.

Use By Experienced Teams

Winner = Trunk-based development

Because all your team members will be accessing the main branch on a regular basis with trunk-based development, any errors will be immediately visible to everyone on the team. If you have a team of veteran coders who are confident in their work, errors are less likely to occur in the first place. But if errors do occur, veteran coders are more likely to shake off the mistake and keep working efficiently.

However, if your team has a few inexperienced coders, the use of the shared trunk may intimidate them. They may worry about making errors that others can see, leaving them operating in a less efficient manner. Additionally, you and other team administrators may not be able to catch errors that less experienced coders make before they upload them to the main branch every day, causing headaches for the project.

Coders can work in their own branches for a longer period of time using other Git branching strategies, whereas they must upload code daily with trunk-based development. It may be easier for you to check the code in the individual branches and find errors from inexperienced coders when you are using other Git branching strategies. 

Use By Small Teams

Winner = Git branching strategies

Because GitHub Flow has fewer development branches than other options, all your team members will work frequently in the main branch. This strategy can become unwieldy when you have a large team where many members are trying to merge to the main branch over a short period of time. This can lead to merge conflicts that cause issues for the project.

So if you have a small team, using the GitHub Flow Git branching strategy works extremely well. GitHub Flow focuses on allowing for short production cycles, which tend to work better with small teams as well. Agile teams also can use GitHub Flow well.

However, if your small development team needs to be able to maintain multiple versions of the code in the project, the GitHub Flow strategy will not work well. It allows for only a single production version. If you have a small team, but you need to be able to maintain multiple versions of the code, the trunk-based development strategy may work better in this particular case.

Implementing Small Changes

Winner = Trunk-based development

When you want to create a coding project that focuses on taking small steps on a regular basis, trunk-based development is the better choice. Because your team of developers must integrate code with the shared trunk on a daily basis, this type of strategy focuses on small changes and improvements. 

If your team wants the option of being able to release the code at any time along the way, trunk-based development strategy is the better choice too. The code is always far closer to being ready for release through this strategy than what will occur with Git branching strategies.

An additional benefit of implementing small changes means that any errors that occur will have a minimal effect on the overall project. If your team chooses to only merge large changes with the Git Flow strategy, an error in one of the large changes could set the project back several days. Your developers may have to walk back quite a bit of code to find the error. The use of trunk-based development greatly reduces the chances of having this potential problem.

Should you need to implement a large change to the coding project, trunk-based development may seem like it would not work well. Having to integrate code on a daily basis would seem to limit the size of the coding change you could complete within the day. However, the trunk-based development strategy deals with this situation using branch by abstraction and feature flags.

With branch by abstraction, you can integrate your code into the shared trunk, but you do not have to connect it to the actual working code. Once you upload all of the code needed for the large change to the project over several days, you then can connect your code to the working code in the shared trunk.

Alongside branch by abstraction, you can deploy feature flags within the trunk-based development strategy. The feature flags give you more control over how and when you release your changes to other members of the team. You can have certain team members look at the code you implemented through the branch by abstraction by marking it with a feature flag, rather than exposing the code to the entire team. 

You also can use feature flags to hide certain segments of your integrated code from end-users until other team members have a chance to test the code segments and make comments, while still following the trunk-based development strategy.