What is "Merge Branches?"
Many users find the word "merge" to be confusing, since it seems to imply that we start out with two things and end up with only one. I'm not going to start trying to invent new vocabulary. Instead, let's just try to be clear about what we mean we speak about merging branches. I define "merge branches" like this:
To "merge branches" is to take some changes which were done to one branch and apply them to another branch.
Sounds easy, doesn't it? In practice, merging branches often is easy. But the edge cases can be really tricky.
Consider an example. Let's say that Joe has made a bunch of changes in $/branch and we want to apply those changes to $/trunk. At some point in the past, $/branch and $/trunk were the same, but they have since diverged. Joe has been making changes to $/branch while the rest of the team has continued making changes to $/trunk. Now it is time to bring Joe back into the team. We want to take all the changes Joe made to $/branch, no matter what those changes were, and we want to apply those changes to $/trunk, no matter what changes have been to $/trunk during Joe's exile.
The central question about merge branches is the matter of how much help the source control tool can provide. Let's imagine that our SCM tool provided us with a slider control:
If we drag this slider all the way to the left, the source control tool does all the work, requiring no help at all from Joe. Speaking as a source control vendor, this is the ideal scenario that we strive for. Most of us don't make it. However, here at SourceGear we made the decision to build our source control product on the .NET Framework, which luckily has full support for the kind of technology needed to implement this. The code snippet below was pasted from our implementation of the Merge Branches feature in Vault:
public void MergeBranches(Folder origin, Folder target)
ArrayList changes = GetSelectedChanges(origin);
DeveloperIntention di = System.Magic.FigureOutWhatDeveloperWasTryingToDo(changes);
Boy do I feel sorry for all those other source control vendors trying to implement Merge Branches without the DeveloperIntention class! And to think that so many people believe the .NET Framework is too large. Sheesh!
Best Practice: Take Responsibility for the Merge
Successfully using the branching and merging features of your source control tool is first a matter of attitude on the part of the developer. No matter how much help the source control tool provides, it is not as smart as you are. You are responsible for doing the merge. Think of the tool as a tool, not as a consultant.
OK, I lied. (Stop trying to add a reference to the System.Magic DLL. It doesn't exist.) The actual truth is that this slider can never be dragged all the way to the left.
If we drag the slider all the way to the right, we get a situation which is actually closer to reality. Joe does all the work and the source control tool is no help at all. In essence, Joe sits down with $/trunk and simply re-does the work he did in $/branch. The context is different, so the changes he makes this time may be very different from what he did before. But Joe is smart, and he can figure out The Right Thing to do.
In practice, we find ourselves somewhere between these two extremes. The source control tool cannot do magic, but it can usually help