git - Visual Studio 2015 GIT 是否使用 3 路 merge ？

Question

当我使用 Visual Studio 2015 的 merge 工具来修复冲突时，它的性能似乎比我在 GIT 的命令行中使用 P4Merge 时更差(几乎没有发现任何冲突)。

这是因为工具本身吗？ Visual Studio 2015 的 merge/差异工具是否为 GIT 提供 3 路 merge ？

Answer 1

TL;DR :Visual Studio 在 merge Git 存储库和尝试解决出现的冲突时进行三向 merge 。目前尚不清楚为什么 VS 在解决该冲突时会不如 P4Merge，但在不知道其他任何事情的情况下，我怀疑 P4Merge 比 inconsistent line ending configurations 更好.

merge 过程有两个阶段:首先，执行 merge 并生成包含来自两个分支的新更改和(可能)冲突的组合树，其次，冲突解决阶段。

在 Visual Studio 中，第一阶段是常规的 git merge ，这确实是三路 merge 。找到“merge 基础”，这是两个分支中都存在的最后一个提交；这是您的两个分支最后一次 merge ，或者是从另一个分支创建一个分支的点。

然后通过确定每个分支中哪些文件已更改，将它们与共同祖先进行比较，在树级别执行三路 merge 。如果一个文件在一个分支中发生了更改，那么该分支的更改将包含在新树中。如果一个文件在两个分支中都发生了变化，那么我们需要在文件级别进行三路 merge ，这非常相似，并将每个分支中的文件与其共同的祖先进行比较。现在，如果文件的任何区域在一个分支中发生了变化，相对于共同的祖先，那么我们将在 merge 文件中包含该更改的区域。但是如果两个分支都改变了同一个区域，那么就会产生冲突。

Git 将在工作目录中生成一个带有冲突标记的文件，但它也会记录这两个文件及其共同祖先，以便您可以使用 merge 工具(如 Visual Studio 或 P4Merge)。

(请注意，当您使用 Visual Studio 执行 merge 时，它使用 libgit2 库，尽管 it produces the same results 作为 Git 本身。)

一旦发生 merge 冲突，您的 merge 工具可以获取这三个文件并为您提供解决冲突的图形体验。通常，每个工具的第一步是尝试再次进行文件级 merge ，并将创建一个新的“结果”文件(通常显示在三个 Pane 的中间 Pane 中，两侧各有两个分支，或者在两个分支文件的上方或下方不太常见)。

此结果通常会包括未自动 merge 的任何重叠区域，并且 UI 通常会提示您解决无法自动 merge 的重叠区域。一般来说，我的经验是这里没有太大的区别，但肯定会有变化。特别是:

一些工具可能更积极地将彼此靠近的小冲突连接在一起，这可能会产生更少但更大的冲突，可能更容易解决 - 例如，如果您有多个冲突，每个冲突可能是更可取的将它们压缩成一个单一的、更大的冲突。

一些工具可能会进行编码翻译，这样您就可以正确地 merge 一个文件，该文件在共同祖先中为 UTF-8，在一个分支中为 UTF-16，在另一个分支中为 Latin1，并以其中一种编码(甚至完全不同)。

某些工具可能会忽略空格更改。我有一种预感，这可能是您看到 Visual Studio 和 P4Merge 之间差异的地方；众所周知，行尾配置很难在 Windows Git 客户端的整个团队中进行设置。一个简单地忽略行尾差异的 merge 工具可以产生比没有的更好的体验。

您甚至可以使用了解文档结构的工具:例如， merge 两个 XML 文件通常不会尝试了解 XML 的结构，而是 you could use a tool that understood XML避免像空白更改这样对文件的含义实际上并不重要的事情。