There are currently 4 branching strategies and with this post you should be able to know when to use them. In which situations one is more appropriate than the other? Without further ado, let’s jump into them.
This is suitable for teams that are migrating from old style subversion to git. You heard about git, but you are still comfortable with SVN. You want the migration to be smooth. The same concepts are still there but the commands are different. This is perfect for you. If the team is small (eg 2-3 developers) based in the same location this strategy can work without too many problems.
You can do code reviews in pairs. The advantage over SVN is that the merges are not painfully anymore. If something breaks your colleague can shout at you to fix it. For medium to big teams this solution should be temporary(1-2 sprints), just for the purpose of getting developers up to speed with git. How it works you can find here.
This was widely used some years ago, thankfully to this article. Nowadays it has lost some ground to the feature branch strategy. But nevertheless it works. I’ve used it with success. The main idea is that you have a branch from where you do your deployments(master) , a branch where developers work(dev) and some intermediate short-lived branches (release, hotfix). When I say short-lived I mean that the release branch will be alive for the testing period, hotfix for the period of fixing and deploying hotfixes. There are also feature branches suitable for developing long-running stories(in a sprint). When a story will get a feature branch that depends on some rules agreed in the team(eg all stories estimated more than 5 story points).
Code review is a little tricky here. You can use a tool like Crucible, but this means that you are in charge of selecting what needs review and what’s worse is that the code is already commited and pushed. This means that an error could be already propagated before the fix is in place. The commit history is clean and readable.
This also requires a code freeze. That means at some point the team should stop working on dev and the release branch will be created. Any issues that the testers find it must be fixed on the release branch. When the release is bug-free(yeah right) it will be merge into master and dev.
This is suitable for small to medium teams. The rule here is that the dev branch should be stable, as they are constant rebases from it. The risk is obvious, you don’t want to interrupt people as they are doing their work. Not suitable in CI/CD process. In order to signal that the build is broken CI is present and it will signal the others(email, communication tools) that they should not commit anything until it will be fixed.
Feature branch strategy
Everyone will get its own branch, even for fixing typos. He/she can work on it in isolation on stable code. This means the work can be done faster without interruptions.
After the work is done a pull request(or merge request) should be created for the purpose of code reviews. Some rules must be set for code reviews. (eg at least 2 approvers). The code review is transparent and will contribute to team’s growth. Code reviews done in this way means better code quality and fewer bugs. The main branch should always contain stable code. This is suitable in a CI/CD process when continuous testing is applied.
Sure, merging could turn out to be hell. If two or more developers are working on the same lines of code, well things could get out of hand. The solution: merge often. Merge from the stable branch(usually dev) or other feature branch if you are dependent on other’s colleague unfinished/partially done work. More importantly merge the dev branch before creating the merge request. Run tests after to make sure nothing is broken. No developer will need to spend the nights on fixing merge issues before the release, if we follow this rule. The person who does the merge is decided by the team; it can be the person who created the merge request or another developer.
The git history will be a mess. Unreadable. Reverting could turn out to be hell. You could lose commits in merges. In theory should not happen. But it does, even if rarely. In that situation an experienced git developer can solve it. Thanks to git reflog nothing is lost. Even if the navigation in the reflog can be tricky, it can be done. History can be simplified using rebase instead of pull.
As we can see this introduces a level of complexity that can seem overwhelming at the beginning. But it’s really not. You do need discipline. And fairly good knowledge of git. This is intended for medium to big teams that are familiar with git.
Each developer has a server-side repository which is forked from the original one. Code can be integrated without the need to access the original repository, but the changes will not get into the original repository until the maintainer accepts them. He is the one who has to do the code reviews and also the merges.
Suitable for open-source projects where many developers are working on the same code. Global teams including 3rd party developers that you don’t know or trust.
These strategies work. They are tested and proven to work. But alas, they are guidelines. Wait what? Yes. These are globally known and accepted, but that does not mean you cannot create your own. And sure, convince the whole world that yours work and probably it will be globally accepted. Or don’t. If it works for you and your team that’s means it’s good. You can mix these strategies, you are in charge.