Last year, Microsoft released its branching and merging guide. There are branches for promotion, branches for side development, and branches for service packs and hot fixes—lots of branches, indeed. The guide suggests a main trunk to which all development is merged. From there it goes up the promotion branches to test and production.
Recently, a contributor to a LinkedIn blog titled “Merging and Branching” recommended branching for a unit of work or for promotion. That’s a lot of branching, especially considering that each merge operation requires re-testing of the functionality being merged. Merging and testing are not fun activities. Yes, they can be automated to a certain extent—if your tests are all automated.
But even so, look at your files and their branch structure and you’ll find that you need a roadmap to keep score. Multiply this by the number of files and things can get pretty scary, especially if a couple of key staff members decide to change companies. I’ve heard many horror stories in which this occured.
Branching and merging are necessary, but they can be minimized to reduce the overhead. My philosophy is simple: Create a new branch when you need to support the old one. So when you wish to support release 1 and you have some release 2 changes to make, don’t start planning when the main trunk is going to arbitrarily switch from release 1 to 2, which changes the process for all developers working on those two releases.
Use a branch-per-release strategy—a main branch for each major release. Release 1 changes always go to the release 1 branch; release 2 changes go to the release 2 branch; and so on.
Insist on peer reviews and change-unit testing for all software that is checked in. Then you will have fewer change roll-backs, and you’ll find that in most cases, with a branch-per-release strategy, it is quite acceptable to check in directly to the release branch. This is all part of the “new branching standards for configuration management,” suggested by yours truly.
Next, leave the workspace as the place for most merging and re-testing. The workspace is likely already set up to retest merge changes, just as it has been for any other changes in the edit-compile-test cycle. In the end you’ll find a much cleaner and consistent branch structure for your files that doesn’t actually need a branching and merging guide—a single slide will do.
Finally, look for a tool that allows you to promote a change by promoting the status of the change, rather than requiring a merge into a new promotion branch. Although there are not many of these available, they are well worth considering and will leave you with a branch structure that has a sequence of horizontal revisions and a sequence of vertical release branches.
This is the type of branching that encourages the “structure-aware SCM tools” identified by my colleague Steve Berczuk in his “Should Agile Teams Minimize Branching?” story.
Do you have any tips on branching and merging that you would like to share? Feel free to respond below in the comments section.
