I like this diagram which illustrates what we're trying to achieve with this scheme.
This shows what a git tree would look like using this workflow. Below are what happened during each stage. Commit A-C: Made on branch 0.10.0 Commit D: Made on branch 0.10.0, tagged as rc1, new 0.11.0 branch is created Commit E-F: New features added to 0.11.0 branch Commit G: Bug fix on 0.10.0 branch, immediately merged into 0.11.0 branch Commit H-I: New features added to 0.11.0 Commit J: Test added on the 0.10.0 branch, immediately merged into 0.11.0, tagged as 0.10.0 release Commit K-L: New features added to 0.11.0 At this point, all development and testing should be done on 0.11.0. It's possible at some point bugs will be found on the 0.10.0 release. Depending on the priority of bug, we can either punt the bug to spin 11 and the fix goes on the 0.11.0 branch, or if it's critical, we can create a new 0.10.1 branch off of 0.10.0 and do the same process while merging fixes into 0.11.0.
Powered by a free Atlassian Confluence Open Source Project License granted to NCSA OpenSource. Evaluate Confluence today.