TFS合并算法问题

我们使用TFS2010，有三个分支：开发->质量保证->生产

在这个特定的示例中，我们决定将方法参数类型和名称从“Guid reportGuid”更改为“int reportId”。我们在QA分支中进行了此更改，并将其签入。现在我正试图将这一变化从QA转移到开发分支。通常是反方向进行的，但在这种特殊情况下，我们做了我们所做的。是合并工具的屏幕截图。正如您从屏幕截图中看到的，Dev分支中文件的最后一次签入获得了变更集编号30282和QA-31002（更新于30282）。对我来说，很明显，新的变更应该覆盖旧的变更。但TFS merge所做的恰恰相反。它将来自Dev分支（30282）的旧代码应用于来自QA分支（31002）的新代码，结果没有得到更改

有人能解释为什么TFS合并会这样吗？

---

提前谢谢。

这个屏幕截图上好像有合并冲突，对吗

首先，不要使用VisualStudio/TFS的合并工具，它既不有效也不直观。使用免费的KDiff3或Beyond Compare可以获得更好的自动合并和更友好的用户界面

第二，据我所知，TFS中并没有时间一致性（我可能错了，但我从来没有听说过）。您提到的两个变更集不在同一个分支中，因此TFS不关心哪个变更集发生在另一个之后，以及它的含义

第三，合并的方向不会改变branch1到branch2或branch2到branch1的任何内容。唯一的变化是两个分支是否直接相关

对我来说，你的问题主要是一个基于GUI的问题，或者你可能使用了自动合并功能，这在冲突的情况下一点都不聪明

更改合并工具如下

远离自动合并

---

您正在发布一个三方合并工具的屏幕截图，我怀疑您将其归因于许多智能。TFS使用任何3路合并工具来解决冲突-默认情况下，它包括图中所示的工具，但是您可以将其配置为使用

当TFS检测到冲突时（在本例中为合并冲突，即文件在两个分支中编辑，然后合并），它将尝试删除文件的内容。如果无法进行自动合并，则需要使用已配置的三向合并工具来解决冲突。TFS只需将该工具交给3条路径：“源”（分支中作为合并源的文件）、“目标”（分支中作为合并目标的文件）和“基”或公共祖先

公共祖先是在两个分支之间合并的文件的最后一个版本。如果未执行合并，则公共祖先是文件分支所在的变更集。直到您第一次将更改从源合并到目标，这种情况才会改变。例如，考虑<代码> $/main /A.txt < /COD>在变更集2中分支为<代码> $/分支/A.TXT< /COD>。如果编辑发生在

$/Main/A.txt

（作为变更集3），而编辑发生在

$/Branch/A.txt

（作为变更集4），那么当您尝试将

$/Branch

合并到

$/Main

时，您将在

A.txt

上发生合并冲突。本例中的公共祖先是变更集2（分支的版本）

如果要在合并工具中解决该冲突并签入结果（作为变更集5），那么下次从

$/Branch

合并到

$/Main

时，

A.txt

的共同祖先将是变更集5。（事实上，如果在TFS冲突解决期间调用“将源代码与基代码进行比较”或“将目标代码与基代码进行比较”，则应该能够看到公共祖先代码及其版本信息。）

在任何情况下，一旦调用了合并工具，该工具最终都有责任提示您处理这些更改。工作流依赖于工具，但典型的合并工具将逐行比较文件，并将每一行标识为以下内容之一：

• 未更改：源和目标中来自祖先的未更改行
• 共同的：从共同祖先更改的行，但相同
• 冲突的：源和目标中已更改且内容不同的行
• 仅源代码：仅在源代码中更改的行（目标与公共祖先相同）
• 仅目标：仅在目标中更改的行（源与公共祖先相同）

如果不存在冲突行，则可以执行“自动合并”，这意味着通过从源获取仅源行、从目标获取仅目标行以及从任一文件获取公共行来修改公共祖先，以生成合并输出。（如果可能，TFS将提供“自动合并”选项。）

请注意，仅仅因为自动合并是可能的（并且通常在实践中是有效的），它就和获取行一样简单，并且没有执行语法检查，所以您的

某些3向合并工具可能提供一种模式，在这种模式下，它们会执行部分自动合并（默认情况下，在打开时或在某些交互之后），使用公共行、仅源行和仅目标行，然后要求您手动解决冲突

屏幕快照中的合并工具是与Visual Studio ALM捆绑的默认工具。TFS 2012中的工具比该版本有了显著改进。不管怎样，你可能会有一个更好的经验，与一个

请注意，尽管有标签，合并工具实际上并不知道哪个文件按时间顺序更新。（TFS向合并工具提供标签，为您提供有关