The diagram above shows how simple the Candidate Release Code Branching Strategy is. The abbreviations and symbols on the screen are as follows.

• Master = Master branch (yellow bar), time is from left to right
• F = Feature branch (green bar)
• D = Defect branch (green bar)
• R = Release branch (orange bar)
• Green arrow = Merge to release branch from feature branch
• Orange arrow = Merge to master branch from release branch
• Yellow arrow = Sync to feature branch from master branch. A sync is a merge from the master to a branch, and is also referred to as a reverse merge.

The rules of the CR code management strategy are straight forward and intuitive.

1. The Master branch code looks like what is running in production.
   
   
2. New feature and Defect branches are created from the Master. Examples: F1,F2,F3,D1
   
   
3. Developers work on this Feature branch and also have QA validate their work for this feature.
   
   
4. When the developers are planning a release they create a Candidate Release branch, R1, from the Master and merge the features to that branch. In this case combining F2 and F3. Do not delete these feature branches until the code in them has been merged to the Master.
   
   
5. Some extra QA is done on this Release branch and maybe some bug fixes and then it is released to production. However, if at the last minute, it is determined that, for example, only one of two features can be released then a new Candidate Release branch can be created and only F2 is merged to it and not F3. This replacement Release branch is not shown in this diagram to reduce clutter. Abandoning a Release branch does mean that some of the bug fixes that were done on it might need to be manually applied to the new Release branch. There is always a risk of manual changes being necessary once features are combined, but combining the features later instead of earlier minimizes this risk. The abandoned Release branch can be deleted once it has been determined that nothing on it is needed anymore. In this case the F3 branch is still alive and will be combined into a future Release branch when it is ready.
   
   
6. Once the production release is determined to be stable, usually a couple days, then the Release branch code is merged to the Master branch.
   
   
7. Feature branches that are isolated for a long time, like F1 in the diagram, should be synched with the Master branch whenever the Master is updated to make the final merge back to the Master easier.