tfs - TFS合并算法问题

Question

我们使用TFS 2010，有三个分支：开发->质量检查->生产。

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

有人可以解释为什么TFS合并会这样吗？
提前致谢。

Answer 1

您正在发布三向合并工具的屏幕截图-我怀疑您将其归功于许多聪明才智。 TFS使用任何3向合并工具来解决冲突-默认情况下，它包括如图所示的一个，但是您可以将其配置为使用any 3-way merge tool of your choice。

当TFS检测到冲突时（在这种情况下为合并冲突，即在两个分支中都编辑了文件然后进行了合并），它将尝试automerge文件的内容。如果无法进行自动合并，则将要求您使用配置的3向合并工具来解决冲突。 TFS只是简单地使用了该工具的3条路径：“源”（分支中作为合并源的文件），“目标”（分支中作为合并目标的文件）以及“基础”或通用祖先。

共同祖先是两个分支之间合并的文件的最新版本。如果未执行合并，则公共祖先是文件分支所在的变更集。在您第一次合并从源到目标的更改之前，情况将一直如此。例如，考虑$/Main/A.txt在变更集2上分支到$/Branch/A.txt。如果在$/Main/A.txt上进行了编辑（作为变更集3），并且在$/Branch/A.txt上进行了编辑（作为变更集4），那么当您尝试合并时$/Branch到$/Main，您将在A.txt上发生合并冲突。在这种情况下，共同祖先是变更集2（分支的版本）。

如果要在合并工具中解决该冲突并检入结果（作为变更集5），那么下一次从$/Branch合并到$/Main时，A.txt的共同祖先将是变更集5。 （实际上，如果在TFS冲突解决期间调用“将源与基础进行比较”或“将目标与基础进行比较”，则您应该能够看到公共祖先及其版本信息。）

无论如何，一旦调用了合并工具，提示您处理这些更改的最终责任就是该工具。该工作流程取决于工具，但是典型的合并工具将逐行比较文件，并将每一行标识为以下内容之一：


不变：祖先在源和目标中没有变化的行
共同的：从共同祖先更改的行，但同样如此
冲突：源和目标中都已更改且内容不同的行
仅源：仅在源中发生更改的行（目标与公共祖先相同）
仅目标：仅在目标中发生更改的行（源与公共祖先相同）


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

请注意，仅因为自动合并是可能的（并且通常在实践中有效），它与采取行一样天真，并且不执行语法检查，因此您的automerged output is not really what you want很有可能。

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

屏幕快照中的合并工具是Visual Studio ALM附带的默认工具。与该版本相比，TFS 2012中的工具得到了显着改进。无论如何，您可能对third-party merge tool有更好的体验。

请注意，尽管有标签，但合并工具实际上并不知道哪个文件按时间顺序是较新的。 （TFS为合并工具提供标签，以便为您提供有关那些文件的上下文，合并工具只是将它们视为不透明字符串。）“按时间顺序更新”也不一定是所有分支策略中最好的合并策略。 （我在使用要素分支策略的团队中工作-我的要素分支具有相对较高的速度，并且我合并了来自主分支的更改，该主分支以相对较慢的节奏从所有要素分支中进行了经过测试的更改。在这种情况下， ，按时间顺序排列并不重要，无论如何我都需要合并冲突。