Release Based Branching

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 -

Next Recommended Reading Creating A Release Definition In VSO