我有一个发布分支（RB，从C5开始）以及主干（C10）上的变更集，我现在想要合并到RB上。
文件在C3处有变化（两者共用），RB上的CS 7中有一个，C9（中继）中有一个，C10中有一个）。因此，我更改的文件的历史记录如下：
RB: C5 -> C7
Trunk: C3 -> C9 -> C10
当我将C10从trunk合并到RB时，我希望看到一个合并窗口显示我
C10 | C3 | C7因为C3是共同的祖先修订版，C10和C7分别是我的两个分支的提示。但是，我的合并工具会显示C10 | C9 | C7。
我的合并工具配置为显示%1(OriginalFile)|%3(BaseFile)|%2(Modified File)，因此这告诉我TFS选择C9作为基本修订。
这完全出乎意料，完全违背了我在Mercurial或Git中使用的合并方式。我是不是出了问题，或者是TFS试图通过合并让我疯狂？
这是默认的TFS合并行为吗？如果是这样，您是否可以通过这种方式深入了解他们选择实施的原因？
我正在使用TFS 2008和VS2010作为客户端。
答案 0 :(得分：13)
我在TFS分支和合并方面有一些类似的初步斗争（我们有开发，集成和主要分支）。
简短版本是您无法直接从提示合并到共同的祖先。
因此，如果C3分支到C5，那么C7分支到C9，该工具提供的内容在TFS如何工作的背景下是有意义的。你基本上需要从C10 / C9到C7，然后从C7到C3。
用一个更具体的例子来说明一个不同的方式，这就是我们如何处理项目中的多级分支和合并。
我们从trunk / main开始。
然后我们分支到集成分支。
然后我们（这是关键）从集成分支到我们各自的开发分支，以便我们可以处理即将发布的版本。
当开发分支中的更改完成时，我们首先通过从集成到我们的开发分支合并来反向集成（因此我们接受其他所有人的更改）。然后，我们通过从我们的个人开发分支转到共享集成分支来转发集成。
一旦集成通过QA，我们然后通过合并主干到集成进行反向集成（以防万一中有任何修补程序），然后将集成中的所有组合更改向下集成到main。
在发布日，我们从main进行最后一个分支到我们随后部署的新版本分支。
基本上，在TFS中，您总是必须在分支/合并树上上下移动从树干到肢体到分支到叶子 - 您不能在任何时候绕过分支层次结构中的任何步骤。
隐喻地说，TFS分支和合并更像是树懒爬上一棵树而慢慢地下到树枝的末端，而不会让它失去它的抓地力而不是在分支之间跳跃的猴子;）
需要一点时间习惯，但一旦完成（特别是一旦你习惯了前向集成/反向集成范例），它就会很有效，特别是当你有几个人都在进行开发而你需要包装时在没有让事情困难的情况下完成每个人的改变。
希望有所帮助！
答案 1 :(得分：0)
之前我正在环顾这个网站并看到这个网页，这有用吗？
答案 2 :(得分：0)
我认为你可能有错误的合并方法，因为你所描述的是完全可能的，它对我有用。但是你总是要记住，当你开始分支主分支时，要做正确的RI（反向积分）和FI（前向积分）。搜索codeplex for branching guidelines and best practices。
实质上，任何退回到主分支的更改都必须在返回到其他分支之前返回到其他分支。这是最佳实践并且每次都有效，之后，您可以继续从分支机构返回到主干线。