Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / DevOps / TFS

Team Foundation Server: Guide to branching and merging with TFS 2010

5.00/5 (1 vote)
7 Jan 2016CPOL3 min read 25K  
I often get developers who are unfamiliar with the branching and merging process within TFS asking me how it works, so I've put together a short guide that explains the basics.

Contrary to popular belief, on the whole Microsoft haven't done too bad a job with the branching and merging side of TFS in 2010. If you're new to all this, it all takes place within source control explorer. Navigate to team explorer, connect to your team foundation server if you're not already and open the team project you're working on. TFS will busy itself loading the work items, etc. but all we're interested in is the last item on the list, source control explorer. Once source control explorer is loaded you should see a list of all the team projects, which hopefully includes yours. Expand the node for your team project and you should see the list of current branches. We're ready to begin. We'll be focusing on an example of creating a Release branch from Main and then merging that branch back in to Main (assuming that some changes have been made on the branch in the interim)

Branching

Branching is slightly different from merging, aside from the obvious, in that the activity happens directly on the server, rather than in your local workspace. Remembering our example from above, right click on the Main branch and select Branching and Merging > Branch from the context menu. Name this branch Release and leave the defaults as they are. Click the Branch button and you should see your new Release branch created in source control explorer at the same level as Main. That's it. You can now perform a Get Latest on this new branch and edit as normal. At some future point, once you've made some changes to the Release branch, you'll need to merge those back in to Main.

Merging

As a general rule of thumb, try to ensure that your work space is clean and free from clutter. If you have any files checked out, either shelve or revert them. That way, if you need to revert the changes you won't lose anything else you were working on. You also won't pollute the merge with changes that aren't specific to it.

Before doing anything, perform a Get Latest on the target branch, Main. Next, right click on the Release branch, which is the source for the merge, and choose Branching and Merging > Merge from the context menu. It should default to Main as the target, ensure that it is if not. You can either Merge all changes up to the latest branch or choose specific changesets. For most merge operations I've been involved with, merging happens with the latest version of the target repository.

Click the Finish button and, if there are no conflicts, you should have a change set in your local work space that contains all of the changes since the branch was created. If there are any conflicts you will need to resolve each of those in turn before you are ready to commit the merge back into the Main branch. Add a nice commit message so that everyone knows that this is the result of a merge and job done.

View original article

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)