Branching and Merging Anti-Patterns

I came across a helpful article on MSDN today, on the subject of branching and merging in source control. What grabbed my attention was a list of "branching and merging anti-patterns". Sadly, my current company is guilty of a few of these. Here's the list from the article:

You know you are on the wrong track if you experience one or more of the following symptoms in your development environment:

• Merge Paranoia—avoiding merging at all cost, usually because of a fear of the consequences.
• Merge Mania—spending too much time merging software assets instead of developing them.
• Big Bang Merge—deferring branch merging to the end of the development effort and attempting to merge all branches simultaneously.
• Never-Ending Merge—continuous merging activity because there is always more to merge.
• Wrong-Way Merge—merging a software asset version with an earlier version.
• Branch Mania—creating many branches for no apparent reason.
• Cascading Branches—branching but never merging back to the main line.
• Mysterious Branches—branching for no apparent reason.
• Temporary Branches—branching for changing reasons, so the branch becomes a permanent temporary workspace.
• Volatile Branches—branching with unstable software assets shared by other branches or merged into another branch.
  • Note   Branches are volatile most of the time while they exist as independent branches. That is the point of having them. The difference is that you should not share or merge branches while they are in an unstable state.
• Development Freeze—stopping all development activities while branching, merging, and building new base lines.
• Berlin Wall—using branches to divide the development team members, instead of dividing the work they are performing.

The most costly I would say is a "development freeze" which can leave whole teams of developers unproductive for weeks at a time.

The most common one I have run into is probably "merge paranoia". Some developers are adamant that the source control software is riddled with bugs that will ruin your work given the slightest opportunity. They couldn't possibly have used the tool wrong. Thus multiple checkouts are often disabled, and branches are never merged back into the tip - bug-fixes are done twice.

As for "branch mania", what can I say? Some managers just seem to sleep easier if they know there was a branch made, "just in case" we need it.

And if there is perhaps one missing, I would add "wrong way branch", where a branch is made and then the tip is renamed so that the branch can take over the project name of the original tip. Guaranteed to cause pain if anything was checked out before this hare-brained scheme is put into effect.

Technorati Tags: source control,branching,merging