TFS:使用主分支的更改更新分支

发布于 2024-10-22 06:31:21 字数 163 浏览 6 评论 0原文

所以,我们有我们的主开发线,我创建一个分支,开发人员 b 创建一个分支。我们俩都做一些工作。开发人员 b 完成他的工作,合并回主开发线。我知道他的更改会影响我,我不想稍后再处理冲突,而是想使用现在主开发行中的更改来更新我的分支,这样我就可以在合并之前在我的分支中处理它们回到主程序。

我该怎么做?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

伴随着你 2024-10-29 06:31:21

从 Visual Studio 中,打开源代码管理资源管理器:

  • 查看|团队资源管理器
  • 从团队资源管理器中选择您的团队项目,将其展开,然后双击源代码管理
  • 在源代码管理资源管理器的左侧窗格中,选择您的< em>团队项目。
  • 在右侧窗格中,找到您的主线分支,右键单击并选择合并...
  • 目标分支下拉列表中,选择您的开发分支。
  • 如果您想要主线中所有更改的子集:
  • 选择选定的更改集单选按钮,然后单击下一步
  • 选择代表从其他开发分支合并到主分支的变更集,然后单击下一步
  • 否则,请保持选择对特定版本的所有更改,然后单击下一步
  • 下一步将选择版本类型。默认的最新版本显然是简单明了且不言自明的:您会将自分支从主线创建以来的所有更改带入您的分支。其他选择很简单,但此处提供的每个选项的教程解释将占用相当多的空间。
  • 完成向导的其余步骤。
  • 单击完成
  • 如果存在任何错误或合并冲突,系统将提示您解决它们,类似于自上次签出以来进行其他更改时将更改签入源代码管理时所看到的情况。
  • 合并完成后,所有更改都位于分支的本地副本中,但尚未提交到源代码管理。在分支上完成所有构建和测试后,您可以签入合并。从 Visual Studio 中:
  • 查看 |其他窗口 |待定更改
  • 确保检查与此合并相关的所有文件,添加描述合并的注释,然后单击签入

我建议将合并(以及任何必要的合并冲突解决、构建中断、测试中断)保留为自己的变更集。也就是说,不要将其他功能与合并混合在一起。粒度变更集使查看源代码控制历史记录和识别单个感兴趣的变更变得更加容易。将合并工作保留在自己的变更集中有助于实现该目标。

还有用于合并的命令行,从 Visual Studio 命令提示符运行 tf merge /?

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文