What is Branching Strategies?
Branches are primarily used as a means for teams to develop features giving them a separate workspace for their code. These branches are usually merged back to a master branch upon completion of work. In this way, features (and any bug and bug fixes) are kept apart from each other allowing you to fix mistakes more easily.
This means that branches protect the mainline of code and any changes made to any given branch don’t affect other developers.
Such a strategy is necessary as it helps keep repositories organized to avoid errors in the application and the dreaded merge hell when multiple developers are working simultaneously and are all adding their changes at the same time.
Need of Branching Strategy:
Having a branching strategy is necessary to avoid conflicts when merging and to allow for the easier integration of changes into the master trunk.
Enhance productivity by ensuring proper coordination among developers
Enable parallel development
Help organize a series of planned, structured releases
Map a clear path when making changes to software through to production
Maintain a bug-free code where developers can quickly fix issues and get these changes back to production without disrupting the development workflow
Git branching
Git branches allow developers to diverge from the main branch by creating separate branches to isolate code changes. The default branch in Git is the master branch.
In Git, a branch is essentially a reference or a pointer to the latest commit in a given context; it’s not a container for commits. As you create new commits in the new branch, Git creates new pointers to track the changes. Git branches, then, can be seen as a pointer to a snapshot of your changes.
Git Branching Strategy:
GitFlow
GitHub Flow
GitLab Flow
Trunk-based development
1. GitFlow
GitFlow enables parallel development where developers can work separately from the master branch on features where a feature branch is created from the master branch.
The GitFlow strategy consists of the following branches:
Master
Develop
Feature- to develop new features that branches off the develop branch
Release- help prepare a new production release; usually branched from the develop branch and must be merged back to both develop and master
Hotfix- also helps prepare for a release but unlike release branches, hotfix branches arise from a bug that has been discovered and must be resolved; it enables developers to keep working on their own changes on the develop branch while the bug is being fixed.
2. GitHub Flow
GitHub Flow is a simpler alternative to GitFlow ideal for smaller teams as they don’t need to manage multiple versions. The main idea behind this model is keeping the master code in a constant deployable state and hence can support continuous integration and continuous delivery processes.
3. GitLab Flow
GitLab Flow is a simpler alternative to GitFlow that combines feature-driven development and feature branching with issue tracking. With GitFlow, developers create a develop branch and make that the default while GitLab Flow works with the main branch right away. GitLab Flow is great when you want to maintain multiple environments and when you prefer to have a staging environment separate from the production environment. Then, whenever the main branch is ready to be deployed, you can merge back into the production branch and release it.
4. Trunk-Based Development
Trunk-based development is a branching strategy that in fact requires no branches but instead, developers integrate their changes into a shared trunk at least once a day. This shared trunk should be ready for release anytime.
The main idea behind this strategy is that developers make smaller changes more frequently and thus the goal is to limit long-lasting branches and avoid merge conflicts as all developers work on the same branch. In other words, developers commit directly into the trunk without the use of branches.
The Tech Platform