TFS: 从 main 更改分支

所以，我们有了我们的主 dev 行，我创建了一个分支，开发人员 b 创建了一个分支。我们都有工作要做。开发人员 b 完成他的工作，合并回主开发线。我知道他的更改会影响到我，与其以后处理这些冲突，我更愿意用现在主开发线上的更改，来更新我的分支，这样我就可以在合并回 main 之前，在我的分支中处理这些更改。

我该怎么做？

58304 次浏览
小开
最佳答案

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.

Good luck, and have fun!


提交答案