My post from an internal blog at my fulltime job:
Yesterday there was a discussion regarding branching and a couple of things bothered me about our approach. The problem area for me is our approach to Feature Branches. Currently, the thought is that we will have a Main line, a Development line (branched from Main) and the potential for Feature Branches to be branched off of the Main line.
The arguments I heard yesterday for this approach:
1. It’s Microsoft Guidance – This part of the argument is probably the most valid, but the documents I read from Microsoft seem to be intentionally vague and open. The patterns and practices book from Microsoft Press that I read gives no fewer than 5 different methods for branching. Some of those methods discuss Feature Branches, but I do not find it clear as to where the source of the branch is from.
2. Microsoft Does It (Yahoo, Google do it) – Ok. This argument might hold if we were an international behemoth with 50,000 employees and $200+ billion dollar market capitalization. Unfortunately, we are not, and probably never will be. Patterning our software designs from successful companies can make sense, but I do not think the same necessarily holds for our infrastructure. Different audiences, different lines of business, different size, different capabilities, different goals… all are good reasons for not rubber stamping their approach. Bottom line is, most of us, including myself have probably been caught saying this, but I do not think it is a good point to be made when speaking of infrastructure specifically.
3. It’s Industry Standard – I have not researched this as much as others, but in the little time that I have looked at it, I can tell that there certainly is no industry standard when it comes to source code management and branching strategies in particular. There are dozens of approaches, and that is for good reason. Each approach needs to be tailored toward a team’s development structure and the structure of their products and releases. Like snowflakes, no two are alike.
My reasons for suggesting that Feature Branches be branched from the Development line:
Really I have only one reason and that is our active development line will be making fixes or feature additions that may need to be merged into a Feature Branch as it is being developed (the reverse could be true too). Under the above structure those fixes would have to be given approval for release and moved into the Main line before they would be able to be merged into the Feature Branch. A baseless merge could be done, but that is clearly not suggested by Microsoft Patterns and Practices. The suggestion is to merge along the hierarchy. The key here is that any code that makes it into our Main line is going to go out in the next new release as Main is branched to create the release branch.
I was asked for an example of where this might happen and couldn’t think of one yesterday. We have not done Feature Branches much in my tenure here. The only time that I can recall that we’ve done something similar is for the GUID release, and the reverse case did occur where we needed to move code from the GUID Feature Branch into the main development line. The EsfId class was moved before the GUID feature was complete to facilitate development of other new features that were occurring in the main development line.
That may not be the best example, but it is one, and should demonstrate the possibility of these situations occurring in the future.
Since we don’t do Feature Branches very often, this is not a critical issue to our moving forward with TFS; thus, the creation of a passive discussion on the topic via the blog.