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.
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.
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.
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.
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.
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.
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.
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! ✌️
My name is Christian. I am a 27-year-old Software & DevOps Engineer with a passion for .NET, Cloud, and Containers. In my spare time, I share my knowledge and love teaching other people about tech.