Branch Strategy is the way you organize development workflow. As a Developer, you will always work on a couple versions of your code. Therefore, it is a good idea to split them into separate types at first.
According to Gitlab documentation (https://docs.gitlab.com/ee/topics/gitlab_flow.html), we can start with the following types:
- Main
- Develop
- Feature
- Release
- Hotfix
As you see, there are two primary branches called Main and Develop. The Feature, Release and Hotfix Branches are treated as one additional type, designed to act as a support branch. Their role in whole process is connected with their names.
Let’s describe branches a bit further.
Main – A branch for your production/live code, which always should be tested and proven to work. We can think about this as a final product. In many cases we are using this branch not as a main branch, but just to keep a backup (one that’s proven to work). We can track a history from there.
Figure 1: https://nvie.com/posts/a-successful-git-branching-model/
Develop – Mainly used as a main branch but created to handle many different features. Often it is used as a branch where code comes to deploy.
Figure 2: https://nvie.com/posts/a-successful-git-branching-model/
Feature – Each developer should clone the main repository into their develop branch for a particular feature. Those branches are basically a target of minor changes from developers and act as their “workbook”, since they could they work on them with many different teams. Due to this characteristic, developers can work without the necessity of synchronizing with other teams any time they want to commit their code. They commit and merge their Feature branches into Develop at some regulated internally time; for example, each Friday. At the end, the feature is merged into the Develop branch mentioned above.
Figure 3: https://nvie.com/posts/a-successful-git-branching-model/
Release – Sometimes developers can use this branch inside our repository as a container for all features designed for a particular release. The release branch represents a complete feature set. The only commits on the release branch are for bug fixes and important chores. A release branch is created off the development branch. The release branch should be merged into the master and also back into the development branch as part of a normal lifecycle.
Hotfix – In some cases, we will notice that something is not working as designed on our app – sometimes just after deployment. In this situation, we have to prepare a hotfix to solve the issue. Hotfix branches are used to quickly patch production releases.
Figure 4: https://nvie.com/posts/a-successful-git-branching-model/
Now we have some knowledge about the types of branches, but how can we apply that knowledge in real scenario? There are couple of strategies we can take. Our first question should be:
“What is a branching strategy?”
We should start from the great rule put forth by Microsoft (https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops):
“Keep your branch strategy simple. Build your strategy from these three concepts:
- Use feature branches for all new features and bug fixes.
- Merge feature branches into the main branch using pull requests.
- Keep a high quality, up-to-date main branch.
A strategy that extends these concepts and avoids contradictions will result in a version control workflow for your team that is consistent and easy to follow. ”
In the above guidelines, Microsoft provides some main rules which act as a standalone strategy and explain what a strategy is according to branching. In other words, a branching strategy ensures your codebase stays pruned and healthy by governing how and when branches are created and used. When reviewing strategies, developers should also take into consideration:
- How many branches you have.
- The longevity of your branches.
- When and where you make commitments, pull requests, and deployments.
- When you should create a new branch.
- What your development pipeline looks like.
If you already know the answers to those questions, you are prepared to read about some ready strategies shared with us by specialists. I will describe some of them further in this article.
#1 GitHub Flow (https://githubflow.github.io/):
As you can guess, this strategy is favored by GitHub. To be compliant with this strategy we should abide by the following rules:
- Anything in the master branch is deployable – it means that all code on this branch is ready to be deployed without any risks to app stability.
- Create descriptive branches off master – each time you start working on new feature/task, provide proper description and name for branch.
- Push to named branches constantly – always try to push changes to named branches for keeping your code updated and safe.
- Open a pull request at any time – don’t hesitate to make PR. If you are sure that your code is ready, just open the PR. Even if you are not sure but you need some review or help from your team, that’s a good place to ask and let your colleagues know that something should be viewed by them.
- Merge only after pull request review – according to the rule above, you should merge only after some approval from somebody else. That’s a good practice to save quality of your work on high levels.
- Deploy immediately after review – all merged changes to the “main” branch should be considered to deployment as soon as possible. Remember that other teams are working on code which is present on the main branch and if you don’t deploy your code, they will continue to work on a deprecated version, which might not be compatible with your changes.
As you see above, most of GitHub’s rules are the logical successors of the branch descriptions. It gives us an additional point of view and regulates those types into logical workflow.
Figure 5: https://geek.justjoin.it/quality-assurance-testing-rules-for-submitter/github-flow
#2 GitFlow (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow):
The previous section covered the GitHub flow, which is a very basic and lightweight solution by a design. GitFlow, on other hand, is a little bit more complex. This strategy uses more of the branch types we described at the beginning of this article. In GitFlow, we will use:
- Feature branches
- Release branches
- Hotfix branches
According to the initial description, the root of this solution is a develop branch. As a reminder, this branch comes directly from the main branch, acting as a backup and history of our product changes. The last stable version is present on the master branch, and the development branch is a branch where there some risk exists, according to any instability of our code.
#3 Trunk-Based Development (https://trunkbaseddevelopment.com/):
In this source-control branching model, developers collaborate on code in a single branch called a ‘trunk’ *. The team resists any pressure to create other long-lived development branches by employing documented techniques. Therefore, they are able to avoid merge hell, do not break the build, and live happily ever after.
Figure 6: https://trunkbaseddevelopment.com/
#4 Gitlab Flow (https://docs.gitlab.com/ee/topics/gitlab_flow.html):
Our Branch definitions mainly come from this particular branching strategy, so all those definitions perfectly describe the GitLab Flow strategy.
Git flow was one of the first proposals to use Git branches. It suggests a main branch and a separate develop branch, as well as supporting branches for features, releases, and hotfixes.
#5 OneFlow (https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow):
OneFlow has been conceived as a simpler alternative to GitFlow. However, “simpler” does not mean “less able”. OneFlow’s branching model is exactly as powerful as GitFlow’s. There is not a single thing that can be done using GitFlow that can’t be achieved (in a simpler way) with OneFlow.
The main condition that needs to be satisfied to use OneFlow for a project is that every new production release is based on the previous release (GitFlow has exactly the same requirement). The vast majority of software projects fulfill that condition. If your project is a web application, for instance, then OneFlow should be a great fit. Most open-source projects could be versioned using OneFlow as well.
