Posted by
Today, I am publishing from a very old document (I created and published in 2017) on Branching strategy for Git (can be applied on other as well). This branching model is also known as GitFlow and is very powerful for scalability needs.
1. Source Code Configuration Management
GIT is a distributed version control system that gives team members a wide flexibility in how they use version control to share and manage code. However, we need a balance between this flexibility and the need to collaborate and share code in a consistent manner. Team members publish, share, review, and iterate on code changes through Git branches shared with others. Adopting a branching strategy as explained below will help us to collaborate better and be more effective in managing version control.
2.1 Branching Process
In this section, it is described when we should create a branch and when we should merge (or integrate) changes from one branch to another branch
2.1.1 Master and Develop Branches
At the start of development, the following things will be performed:
1. Initial frameworks/code will be on Master branch
2. A “Develop” branch is created from Master.
3. Develop branch is the only other long running branch other than Master.
The Develop Branches holds the current hot code and also facilitates continuous integration. This will be the base for all other branches that are created for development and release. Only Hot-Fix branches are created from master branch.
We may have multiple parallel branches for development of different features or bug fixes. Different teams may work on different features or Change Requests and isolation of the different changes is required. These are also referred to as “Feature Branches”.
2.1.2 Feature Branches
At the start of development of feature, bug fix or change request, the following things will be performed:
1. A Feature branch is created from the HEAD of the Develop branch.
2. Perform development work in the feature branch.
2.1.3 Feature Milestone or Interim Development Phase Complete
As the application is developed, it will approach a project milestone at which the feature being developed will be complete to be integrated to the rest of the system. At this point of time, a pull request is created to raise a request for a review and approval for a pull-merge of the feature code back to the development branch.
The steps to perform this are:
1. Merge all changes from the Feature Branch into the Develop branch using pull.
2. Ensure that the CI build is successful, and the updated tag goes back to the source code.
3. Implement Formal build and go ahead with the deployments to Test environment for formal validations
This process is depicted in diagram below.
2.1.4 Development Phase Complete
When the final development phase is complete or at a major milestone achieved, the code needs to transition into a release structure before it can be released to user acceptance testing and ultimately to the Pre-production and production. In this context, “Final” simply means the last phase before a version is released to the production. Further development for other releases may occur afterwards.
In this phase a Release Branch is created from the Develop Branch. It is from this new branch that the code is released to test and when passed as satisfactory, is released to the pre-production and production.
The steps to perform this are:
1. Merge all changes from the Feature Branch into the Develop Branch.
2. Ensure that the build number property in the build definition for the Develop Branch contains the intended major and minor elements of the version number. As this is the Develop Branch, the Build element of the version number should start from 0. If there have been interim phases, the version number should already be correct.
3. Branch from Develop to create a new branch that reflects the version and is held under the Releases branch.
4. Implement CI or Queue a Release Branch build or allow a build to be queued by the build schedule.
5. Release/Deploy the build for testing. Implement necessary approval workflow in the CI/CD pipeline.
This process is depicted in diagram below.
2.1.5Hot Fix Releases
Issues might be raised on a specific version from the formal releases that were done earlier. Before fixing the issue, we need to decide how the fix is implemented and released. There can be multiple scenarios:
a. There is a new release going out to the customer in coming time – In this case, the issue might be fixed on the current development work for that upcoming release (either in a feature branch in case a release branch for it not yet created or in the release branch).
b. The issue is already resolved in a later release, but the customer is still using an older release version
c. The issue needs immediate fix and cannot wait for the next release – Rare scenario, but may happen
In case we need to have a specific hot-fix to be provided, a Hot-Fix Branch is created from the specific release version (tag) from the master branch for implementing and releasing.
The steps to perform this are:
1. A Hot-Fix Branch is created from the specific release version (tag) from the master branch.
2. The fix is implemented in this branch, tested, validated and released back to the customer.
3. At the point of release, the code is also pushed onto Master
4. Merge all changes from the Hot-Fix Branch into the Develop Branch to make sure the fix is available for future releases.
5. In case there are active feature branches that are impacted by the hot-fix, update those feature branches from the develop branch.
6. In case there is an active release branch that should be updated from the Dev Branch for the hot-fix.
7. Merging hot-fix changes might need additional review not to disturb current flow of work and dependencies.
This process is depicted in diagram below.
2.2 Improve code quality with Branch policies
Branch policies help teams protect their important branches of development. Policies such as “require code review”, “merge requirements” etc., enforce code quality and change management standards. After branch policy has been set, changes to the branch are only made through pull requests. Develop branch must have all required branch policies to protect it from being unstable.