Git Branching Strategy

 GIT BRANCHING STRATEGY

Once you start your journey into software development, it won’t take long for you to run into Source Control Management (SCM) systems. By far the most popular of them all is Git. 

Like most other SCMs, Git helps you manage your code in a way that allows for collaboration with team members. At the very core of Git, you will find that branching is one of its most helpful features.

Branching is what allows multiple developers to work on the same project without interfering with what the others are doing. With branching, each developer works on their own branch, and once they are ready to move it into production, they get their branches merged. 

In this guide, you’ll learn why Git branching is so valuable and get introduced to three different branching strategies.

Why is Git branching important?

Before we jump into the different branching strategies, you should know why they’re needed and why branching is so necessary in the first place. 

Branching helps you collaborate with your team members without stepping on each other’s toes. Git branching makes it possible for a full software development team to work on the same codebase simultaneously. However, there are other reasons why you need a branching strategy.

A branching strategy allows you to incorporate Git branching directly into your workflow. The most common use case is to enable Continuous Integration and/or Continuous Delivery. By using different branches, you can run automated tests every time something is pushed to a specific branch, making sure the code works before it gets merged into the production branch.

Automated tests aren’t the only type of tests you can do when you start implementing branching. You can also use different branches to perform A/B testing, deploy the code from two different branches, and redirect customers to one application or the other. This allows much finer control of what is running in the “main” branch that is considered production.

Types of Git branching

There are multiple types of Git branching strategies you can use for your projects. The three branching strategies listed below are a fraction of all the different strategies that exist; however, they are the three most popular strategies at the time of writing.

Git Flow

Git Flow is by far the most popular Git branching strategy out there, and it’s one of the oldest still in use today. It centers around having two branches: "main" and "develop." The principle behind this strategy is that all the code being developed is merged to the develop branch. Once you’re ready to make a release, you open up a pull request (PR) into the main branch. Essentially, this means that every commit in the main branch is a release in itself.

This doesn’t mean that every developer should be pushing into the develop branch every time they have something they need to add to the codebase. Instead they rely on what’s known as feature branches. As the name suggests, a branch is created for each new feature. The team can work on this feature branch until it’s ready to be merged into develop. Typically, at this point the feature is done.

With the feature branch done and ready to be merged into develop, it’s up to the team to decide how exactly they want to accomplish this. Many teams opt for a CI/CD approach and get the branch automatically tested, as well as reviewed by either team members or someone else with insight into the codebase. Once the feature branch has been merged into develop, it is deleted. At this point, you can either wait for more features to be merged into develop, or you can get develop merged into main for a release. In the end, Git Flow is highly defined and leaves teams with very little to decide for themselves, which can be a good thing as it leaves less work on the implementation.

GitHub Flow

Whereas Git Flow is a defined process, GitHub Flow is a bit looser on the concepts, allowing each team to define the way it works best for them. In reality, GitHub Flow doesn’t so much define the parameters on how each new branch should be created, but rather focuses on how the different branches should interact. One big difference from Git Flow is that it doesn’t have any develop branch. All new branches are built out from main and merged directly back into main.

So if GitHub Flow doesn’t dictate what branches need to be developed, what does it dictate? First of all, it defines that branches do need to be created, and that they should be created from main. From here, you can treat your branches however you please. In terms of the flow, there’s no difference between a branch that’s meant for a hotfix or for a full feature.

The other thing that GitHub Flow defines is the need to create a PR to get things merged into main. The PR needs to be viewed as a collaboration tool, where team members can comment on features and code. All in all, GitHub Flow does mean that teams have to work a bit more on the implementation to figure out what makes the most sense, but this also means that it comes with a lot of flexibility.