With teams growing too large, branching has become an important concept for developers. Though there are various strategies to do branching of code, release-based branching is a simple and important strategy. A few pointers for starting with development for a new product are listed below.
- The Master branch is the starting point for any coding team. The new version branch (v 1.0) is created from the master branch.
- The whole development team will commit their code to the v1.0 branch.
- As a best practice, DevOps pipelines/jobs should point to v1.0.
- Once the v1.0 is released to the Production environment following activities are done:-
- Merge v1.0 to master branch
- Change v1.0 to protected branch so that no future check-ins are done by developers.
- Create a new branch v1.1 from the master branch.
- Modify DevOps pipeline/job to point to the v1.1 version so that all future build and deployments are done from v1.1 and not v1.0
![Release Based Branching]()
In case there is a production issue that requires a hotfix then the below approach can be followed.
Create a new hotfix branch vH1_1.0 from the master branch.
Hotfix code should be committed in-branch vH1_1.0
After the hotfix is released to production, the merge of vH1_1.0 should be done to the Master branch as well as to the ongoing release branch v2.0.
I highly recommend Github desktop for all branching and code merging activities as it's very simple to use.
Github URL - https://desktop.github.com