TFS合并是如何工作的？

我有一个发布分支（RB，从C5开始）和一个位于主干（C10）上的变更集，现在我想合并到RB上

该文件在C3（两者通用）、RB上的CS7、C9（主干）和C10上各有一处更改。因此，我更改的文件的历史记录如下所示：

    RB:       C5 -> C7
Trunk: C3 ->             C9 -> C10

当我将C10从主干合并到RB时，我希望看到一个合并窗口显示我

C10 | C3 | C7

因为C3是共同的祖先版本，C10和C7分别是我的两个分支的提示。但是，我的合并工具显示的是

C10 | C9 | C7

我的合并工具配置为显示

%1（原始文件）|%3（基本文件）|%2（修改文件）

，因此这告诉我TFS选择C9作为基本修订

这完全出乎意料，与我习惯于在Mercurial或Git中进行合并的方式完全相反。我是不是做错了什么，还是TFS试图通过合并让我发疯

这是默认的TFS合并行为吗？如果是这样，您能否深入了解他们为什么选择这种方式实施它？

---

我正在使用TFS 2008和VS2010作为客户端。

我以前在这个网站上浏览过，看到这个页面，这有帮助吗

我认为您可能有一个错误的合并方法，因为您所描述的是完全可能的，而且它对我很有用。但是你必须记住，当你开始分支时，主要的分支是做适当的RI（反向积分）和FI（正向积分）。对…进行搜索

---

本质上，任何放回主分支的更改都必须在合并回主分支之前重新放回其他分支。这是最佳实践，每次都有效，之后，您可以继续从分支返回到主干。

我在TFS分支和合并方面遇到了一些类似的初始困难（我们有开发、集成和主分支）

简短的版本是，您不能直接从一个tip合并回一个共同的祖先

因此，如果C3分支到C5，那么C7分支到C9，那么该工具提供的内容在TFS如何工作的上下文中是有意义的。您基本上需要从C10/C9到C7，然后从C7到C3

通过一个更具体的例子，用另一种方式说，下面是我们如何在项目中处理多级分支和合并

我们从主干/主干开始

然后我们分支到集成分支

然后，我们（这是关键）从集成分支到各个开发分支，这样我们就可以处理即将发布的版本

当开发分支中的更改完成时，我们首先通过从集成合并到开发分支来进行反向集成（因此我们接受其他所有人的更改）。然后，我们通过从单个开发分支到共享集成分支来进行前向集成

一旦集成通过QA，我们就通过将主干合并到集成（以防万一main中有任何修补程序）来反向集成，然后将集成中的所有组合更改向前集成到main

在发布日，我们从main做最后一个分支，进入一个新的发布分支，然后进行部署

基本上，在TFS中，您必须始终在分支/合并树上下移动，从树干到枝干再到枝干再到树叶-您不能在任何时候绕过分支继承权中的任何步骤

打个比方，TFS分支和合并更像是树懒爬上一棵树，慢慢爬到一根树枝的末端，而不会失去抓地力，而不是猴子在树枝之间跳跃；）

需要一点习惯，但一旦完成（尤其是一旦你习惯了前向集成/反向集成范式），它就起到了作用，特别是当你有几个人都在做开发，你需要总结每个人的变化而不让事情被践踏的时候

---

希望有帮助

如果您使用标准合并工具（因此请删除已配置的用户工具），会发生什么情况？@Ewald Hofman:这是一样的（除了默认的TFS合并实用程序是crap之外），因此它肯定不会与正在使用的合并工具相关联。@Ewald:这是否使您（或任何其他人）能够回答我的问题？@John:TFS 2008。在Visual Studio 2010中使用它。很抱歉，Jaanus，这并不是完全有帮助。@Bob Palmer:谢谢您的回答。我知道RI/FI模式。然而，这并不能解释为什么TFS选择C9作为基准修订版。我想你可能对我展示的样品错了检验。C5和C7是对我发布分支上的文件的更改（C5标志着发布分支的开始，C7是对发布分支上提交的文件的更改）。啊，现在我更好地理解了您的示例！我怀疑你将C9视为你的基础而不是C3的原因是因为你在C5分支，所以它看起来像是抓住了第一个承诺的基础分支（即C9）。我会在我的一个TFS服务器上测试这个。嗯。。。我制作了一个示例文件，开始并复制了上面的场景-当我开始进行第二次更改（您的C10）时，我将我的原始文件（您的C3）视为我的基础，而不是我的C9等效更改。。。所以肯定还有别的事。为了我自己的利益-你从主干开始，然后在变更集3之后分支到RB，变更集5代表第一次签入RB？是的，我从主干开始，然后在变更集3之后分支到RB（这创建了C5）。TFS中的分支和合并是一个残酷的虐待。。。沿途一定有什么东西重置了它认为的基地，并失去了你与C3的连接-我可以得到你想要的行为，但我有复制（在实验室条件下）你上面的树的好处。