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
.png?ixlib=gatsbyFP&auto=compress%2Cformat&fit=max)
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.
If you want a deeper dive into Git Flow, you can read Atlassian’s guide on it here.
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.
Azure Flow
One of the lesser-known and less used flows was developed by one of the most well-known companies: Microsoft. Contrary to the trend among most companies, they’ve developed a flow that is focused around a set release schedule. That is very much unlike the rest of the industry, which aims to release as often as possible.
Azure Flow does carry some of the features that you see in the other flows, especially the fact that main always has to be buildable. The biggest difference, as mentioned before, is that this flow centers around a set schedule. When it comes time to release a new feature, a branch is created off of the main branch, and this is where the release is prepared. Once a "release" branch has been created, it is never merged back into main.
This type of workflow is mostly suited to big organizations, as it requires a lot more planning than other flows. Not only do you need to make sure that the features scheduled to be included in a release actually get done in time, you also need to have engineers spend time on preparing a release. That’s not to say it’s a bad flow, just more appropriate for those companies with many engineers in many teams.
Git branching with feature flags
Git branching strategies help teams work more collaboratively, as well as allow the use of great features like CI/CD and A/B testing. But as should be clear by now, picking a branching strategy is not as simple as “choosing the best one.” You should make that decision on the basis of your own and your team’s needs, and on whether your priority is structure or flexibility.
No matter what branching strategy you decide to go with, you need to make sure that your features are deployed without any issues. One way to do this is by using feature flags. Feature flags allow you to deploy and test your code without affecting your customers, until you flip a switch and make the new version official.
LaunchDarkly helps with exactly this, allowing you to automate code changes and manage feature flags. LaunchDarkly’s infrastructure also offers you more streamlined control over your deployments and a more modern form of development.
Now that you know more about Git branching strategies, learn how they differ from Trunk-Based Development in this article.
.webp)
