Question

So, we have our main dev line, I create a branch, and developer b creates a branch. We both do some work. developer b finishes his work, merges back into the main dev line. I know his changes will affect me, and rather than deal with the conflicts later, I would like to update my branch, with the changes that are now in the main dev line, so I can deal with them in my branch, prior to merging back into main.

How do I do that?

Answer 1

From Visual Studio, open Source Control Explorer:

• View | Team Explorer
• Select your Team Project from Team Explorer, expand it, and double click Source Control
• In the left-hand pane of Source Control Explorer, select your Team Project.
• In the right-hand pane, find your mainline branch, right-click and select Merge…
• In the Target branch drop-down, select your dev branch.
• If you want a subset of all the changes in the mainline:
• Choose the Selected changesets radio button, click Next.
• Select the changesets that represent the merge from your other dev’s branch into main, click Next.
• Otherwise, keep All changes up to a specific version selected, click Next
• The next step has you pick a Version type. The default, Latest Version is obviously straightforward and self-explanatory: you would be brining all changes since your branch was created from the mainline down into your branch. The other choices are straightforward, but a tutorial explanation of each option available here would take a fair amount of space.
• Walk through the remaining steps of the wizard.
• Click Finish.
• If there are any errors or merge conflicts, you will be prompted to resolve them, similar to what you would see if checking your changes into source control when other changes had been made since last checkout.
• After the merge is done, all the changes are in your local copy of the branch, but they are not yet committed to source control. Once you’ve completed all your builds and testing on your branch, you can check in the merge. From Visual Studio:
• View | Other WIndows | Pending Changes
• Make sure all the files related to this merge are checked, add comments describing the merge, and click Check In.

I recommend keeping merges (and any necessary merge conflict resolution, build breaks, test breaks) as their own changeset. That is, do not mix other feature work with merges. Granular changesets make it much easier to review source control history, and to identify a single change of interest. Keeping merge work in its own changeset helps work toward that goal.

There is command-line for merging as well, run tf merge /? from a Visual Studio Command Prompt.