从 git-merge 的手册页中，您可以使用许多合并策略。
解决 - 这只能使用 3 路合并算法解决两个头（即当前分支和您从中提取的另一个分支）。它试图仔细检测交叉合并歧义，并且通常被认为是安全和快速的。
递归 - 这只能使用 3 路合并算法解决两个头。当有多个共同祖先可用于三向合并时，它会创建共同祖先的合并树并将其用作三向合并的参考树。据报道，通过对取自 Linux 2.6 内核开发历史的实际合并提交进行的测试，这可以减少合并冲突，而不会导致错误合并。此外，这可以检测和处理涉及重命名的合并。这是拉取或合并一个分支时的默认合并策略。
章鱼 - 这解决了两个以上的情况，但拒绝进行需要手动解决的复杂合并。它主要用于将主题分支头捆绑在一起。这是拉取或合并多个分支时的默认合并策略。
我们 的 - 这解决了任意数量的头，但合并的结果始终是当前分支头。它旨在用于取代分支的旧开发历史。
子树 - 这是一种修改后的递归策略。合并树 A 和 B 时，如果 B 对应 A 的子树，则首先调整 B 以匹配 A 的树结构，而不是读取同级树。对共同祖先树也进行了这种调整。
我什么时候应该指定不同于默认值的东西？什么场景最适合？
我不熟悉resolve，但我用过其他的：
递归是非快进合并的默认值。我们都熟悉那个。
当我有几棵需要合并的树时，我使用了章鱼。您可以在大型项目中看到这一点，其中许多分支都进行了独立开发，并且已经准备好整合到一个单一的头部。
章鱼分支在一次提交中合并多个头，只要它可以干净地完成。
举例来说，假设您有一个项目，该项目有一个 master，然后是三个要合并的分支（称为 a、b 和 c）。
一系列递归合并看起来像这样（请注意，第一次合并是快进，因为我没有强制递归）：
但是，单个章鱼合并看起来像这样：
commit ae632e99ba0ccd0e9e06d09e8647659220d043b9 Merge: f51262e... c9ce629... aa0f25d...
我们的 == 我想引入另一个头部，但丢弃头部引入的所有变化。
这会保留分支的历史记录，而不会受到分支的任何影响。
（阅读：甚至没有查看这些分支之间的更改。分支只是合并，文件没有做任何事情。如果你想在另一个分支中合并并且每次出现“我们的文件版本或他们的文件版本”的问题时版本”你可以使用git merge -X ours）
git merge -X ours
当您想将另一个项目合并到当前项目的子目录中时，子树很有用。当您有一个不想包含为子模块的库时很有用。
