Source Control Code Branches: Everyone is Wrong, but Everyone Else is Right.

One size does not fit all. When it comes to code branching it's common for everyone to think that his or her company or team is doing it the right way. "Everyone else is wrong." "This is the way we've always done it." "If we change it there will be confusion." Proper branching in a version control system is one of those topics that gets beaten to death about once a year. Discussions start; meetings are held; policies are established; directives are handed down. Then, about a year later, somebody (this time it was me) decides we should simplify things and the whole thing starts over.

This week I chose to once again challenge the established way of doing things and had some good results. Our previous method has worked fine, but it results in many short branches and therefore lots of merging. Here's the usual plan (we use subversion):

• All feature development takes place on a branch (for example /branches/9.1.4/)
  
• After a release is deployed to production, the code is tagged then merged from the branch back to trunk
• No further development happens on that branch
  
• If maintenance fixes are needed a new branch is created (such as /branches/MAINT-9.1.4/)

The next feature development (9.1.5) could start at any time and sometimes starts before the current feature gets to production. It's a decent strategy and works well, but I decided to upset the apple cart by suggesting we only do the first two bullet points and skip the third and fourth. We would still tag and merge after a release, but instead of dead-ending the branch, developers can put any maintenance fixes on the same branch! What a radical concept! (Okay, maybe not that radical, but I did get a little more resistance than I thought was necessary.) This new method gives us the benefit of fewer branches, less mental overhead, and no need to configure the build server to watch yet another branch. (That last part is my responsibility to perform, so really I'm just trying to avoid extra work.)

I later reviewed the Common Branching Patterns in the Subversion book to support my wacky ideas. What we're doing now is sortof a modified Release Branch style. The Feature Branch style seems nice, too, but it is not as easy to delete branches in our version control system (permissions, y'know). As luck would have it, our corporate Source Code Control Standards supports multiple approaches to branching, but each of them allow for multiple releases from a single branch.

Thus, I give you:

Brad's Common Sense Principles for Source Code Version Control

• Concurrent development should happen in separate branches
• Any release into production should be tagged
• Several releases can happen from a single branch before its end-of-life
  
• The trunk should be kept clean (only feature complete check-ins and refactoring)
  

[What a timely topic! Martin Fowler just recently wrote about something similar in his article FeatureBranch.] How do you do branching, releases, etc., in your version control system?