Skip to main content

My Top 4 Preferred Git Branching Strategies

Looking for a brief/high-level overview of branching strategies? In this post, I will give you my top preferred branching strategies and tell you the pros and cons of choosing them and which one i would choose for what.

Christian Schou

I am sure that you have heard of Git before. Git is a powerful version control system that enables developers to collaborate on software projects.

One of the key features Git provides for developers is branches, allowing developers to make a "copy" of the code into a separate branch, work on their code, and then merge it back into the master/main branch.

Branching Strategies

In this post, I will take a closer look at some of the most used GIT branching strategies I have seen used by clients and within companies where I have been employed.

If you are interested in a more in-depth explanation of each of the Git branching strategies you can easily read more about them here at my site, by clicking on the links in each section taking you to the post about each Git Strategy.

Gitflow Strategy

The first strategy I would like to talk about is Gitflow. Gitflow is a popular branching strategy that makes use of two primary branches - master/main and develop.

gitflow, gitflow branching, gitflow workflow
Gitflow Branching Strategy

Let's talk a bit more about these two branches and their workflows. The master branch holds a production version of the code (the one for release), and the development branch holds the latest development code.

Whenever a new feature is added to the codebase a new feature branch is created from the development branch and then merged back into the development branch.

When the version on the development branch is ready for release, it's then merged into the master branch and then a new version is published/released.

Most of the time I have seen Gitflow being used in large projects, where a release cycle can last for a long time. A big downside is that it can be complex to maintain, as every developer strictly needs to follow a set of rules for how branches, merges, etc... are made in the repository.

Trunk-based Development Strategy

If you are looking for a strategy that allows for frequent releases, then trunk-based development might be what you are looking for. This strategy focuses on a master branch and uses feature flags to separate/isolate new features from production until they are ready for release.

trunk-based development, trunk based git strategy, trunk-based, trunk git
Trunk-based git strategy
The trunk-based strategy is a perfect fit for companies/teams looking into running pure CI/CD (continuous integration) / (continuous delivery).

One thing that can be tough when using this strategy is to make sure that every developer is good a communicating with other developers. If no one communicates you will end up with a sh*t ton of code where features are not isolated properly and conflicts arise everywhere.

I have seen this strategy implemented in big companies where the focus is on getting something delivered, and it's excellent at that, but be aware of having a great test framework, as rolling backward can be a nightmare.

Feature Branching Strategy

One strategy I see a lot of developers use in teams and privately is the feature branching strategy. It's a strategy focusing on developing new features in their own branches.

feature branching strategy, feature branching, git strategy
Feature branching git strategy

Each new branch is made from the development branch, and the feature is developed, tested, and finally merged back into the master branch for a new release. This makes it easy for DevOps, Developers, etc... to roll back a release if there is an error in the release.

This strategy is the perfect fit for small projects, and teams that are looking for an easy Git branching strategy that allows them to implement new features quickly. If you have a large organization I would not recommend this as it can become very complicated to manage large projects with many developers creating lots of features and merging them into the master code base.

If you like this approach but have a large organization, I would recommend having a look at Gitflow and then making feature branches from the development branch instead.

Release Based Strategy

As the name says, the release-based strategy is about making a new branch for each of the releases you are creating for your software project. With this approach you can do all the final bug fixes, tests, etc... before you merge the release branch into the master branch for the final release of the production solution.

release git strategy, release based git strategy
Release-based git strategy

If you are doing a lot of releases or planning to do just that, then this git strategy is a great choice. One thing you have to have in mind is that you need to be very specific about what is being developed in each release and what is tested, as two identical features should be present in two release branches being developed at the same time.

Summary 🥳

In this post I have introduced you to 4 of my top preferred git strategies. Not having a git strategy will cause you a huge headache when the project evolves, so I can only encourage you to pick a strategy and do it now! ⚠️

As you might have noticed, each of the strategies has its forces and weaknesses. I have tried to come up with a brief explanation of what each of the strategies is good for in terms of team size, projects, releases, and the overall development process.

If you want an in-depth explanation with diagrams and examples, please check out the links for each of the git strategies to gain a better understanding making it easier for you to choose the git strategy that matches your needs.

If you have any questions, please let me know in the comments below. Until next time, happy engineering! ✌️

Christian Schou