Branching and Merging
One of the key concepts in any source control system is branching. But why would you want to branch code? The Subversion manual has a great explanation:
Suppose it's your job to maintain a document for a division in your company, a handbook of some sort. One day a different division asks you for the same handbook, but with a few parts “tweaked” for them, since they do things slightly differently.
What do you do in this situation? You do the obvious thing: you make a second copy of your document, and begin maintaining the two copies separately. As each department asks you to make small changes, you incorporate them into one copy or the other.
You often want to make the same change to both copies. For example, if you discover a typo in the first copy, it's very likely that the same typo exists in the second copy. The two documents are almost the same, after all; they only differ in small, specific ways.
This is the basic concept of a branch—namely, a line of development that exists independently of another line, yet still shares a common history if you look far enough back in time. A branch always begins life as a copy of something, and moves on from there, generating its own history
You can create a branch in Team System through the Source Control Explorer. Simply right click the tree and select the Branch option:
In this case, I'm branching the latest version of the Demo Console App to "Sprint 2". I used the default naming conventions that VSTS provides. Once you branch, you must check in your changes for the branch to appear:
Once I commit the branch changes, I now have a branch under my main project:
I then opened a new instance of Visual Studio 2005 and selected File, Source Control, Open From Source control:
Simply highlight the new branch, then provide a new physical folder and click OK to load the newly branched project.
Our demo project is very simple; I quoted some merge sample code provided by James Dawson. Here's class1 in the parent branch:
class Class1
{
public Class1()
{
//
}
public int SomeMethod1(int x, int y)
{
return x + y;
}
}
And here's class1 in the child branch:
class Class1
{
public Class1()
{
//
}
public int SomeMethod1(int x, int y)
{
return x + y;
}
public int SomeMethod2(int x, int y)
{
return (2 * x) - y;
}
}
I then edited the parent branch with a bugfix in SomeMethod1:
class Class1
{
public Class1()
{
//
}
public int SomeMethod1(int x, int y)
{
return x + (y + 1);
}
}
Now I want to propagate that critical bugfix in the parent down to the child branch I created. To do so, I right click the parent folder in Source Control Explorer and select Merge:
Pay attention to this dialog, because the order of the merge is critical. In this case I am merging the parent with the child, but you could certainly opt to merge child changes back into the parent branch, too. Or you could randomly merge with some other branch that has nothing to do with your code. Again-- be careful!
The merge has a conflict. We expected that, because class1 has changed in both the parent and the child:
We need to resolve the conflicts:
Usually you can automatically merge non-conflicting changes, but I couldn't in this case for some reason.
I could also opt to arbitrarily overwrite one version with another, but I really want to merge the changes. So I left "merge changes in merge tool" selected and clicked OK to launch the merge tool:
I then manually changed the method in the bottom (edit) pane to incorporate the change. I could have also clicked one (or both) of the changes in the top pane to automatically enter those changes in the bottom edit pane.
Once you're done, the merge changes are part of your changeset and must be checked in like any other changes. You can also opt to undo your changes if something goes wrong.