Sent from my iPhone
From: LostArchitect
Our development process includes simultaneous development on multiple release paths: while one team is working on the current major release another team is working on the next major and a third team may be work on the one after that. Of course the standard branches for ServicePack and HotFix work on the current production version also exist. Our problem is that we want to provide a simple merge path from main through all of the development branches. We are focusing on trying to (1) minimize the number of merges required for each check in and (2) protect main from becoming polluted with accidental merges from future release branches. The recommended advanced branching pattern suggests creating all of the future release branches at the same time with MAIN as the root:
MAIN
|- RELEASE_1
|- RELEASE_2
|- RELEASE_3My primary issue with this scheme is that changes checked into RELEASE_1 then have to be merged forward into RELEASE_2 and RELEASE_3 through MAIN. It quickly becomes difficult to track what items haven't been merged forward and to which branches. Plus it is difficult to protect MAIN from accidental reverse integration merges from RELEASE_2 and RELEASE_3 while RELEASE_1 is still active.
I am proposing a modified hierarchical branch structure where RELEASE_2 is a child of RELEASE_1 and RELEASE_3 is a child of RELEASE_2.
MAIN
|- RELEASE_1
|- RELEASE_2
|- RELEASE_3Then as each version is released to production, its child branches could be reparented to MAIN and that branch could be locked to prevent further checkins. This allows for a straightforward, sequential merge path and gives us the ability to protect main by denying reverse integration merges on all of the release branches. We can easily monitor what changes haven't been merged into the future releases (everything should always merge forward). By denying reverse integration merges on the release branches, we protect MAIN and ensure that it is only receiving changes from the current release branch. The only hiccup with this plan that I can see (and it seems minor to me) is that after reparenting, we will have to re-merge every change that was checked into RELEASE_2 back into MAIN. But as long as we manage our forward integration merges and make sure that the merge list is clear before performing the reparent, this should be a simple overwrite merge (any conflicts should have been resolved by the merge from RELEASE_1 -> RELEASE_2).
Thoughts? Comments? What am I missing?