你什么时候会使用不同的 git 合并策略？

从 git-merge 的手册页中，您可以使用多种合并策略。

• resolve- 这只能使用 3 路合并算法解析两个头（即当前分支和您从中提取的另一个分支）。它试图仔细检测交叉合并的歧义，并且通常被认为是安全和快速的。

• 递归的- 这只能使用 3 路合并算法解析两个头。当有多个共同祖先可用于三向合并时，它会创建一棵共同祖先的合并树，并将其用作三向合并的参考树。据报道，通过对 Linux 2.6 内核开发历史记录中的实际合并提交进行的测试，这可以减少合并冲突，而不会导致错误合并。此外，这可以检测和处理涉及重命名的合并。这是拉取或合并一个分支时的默认合并策略。

• octopus- 这解决了两个以上的情况，但拒绝进行需要手动解决的复杂合并。它主要用于将主题分支头捆绑在一起。这是拉取或合并多个分支时的默认合并策略。

• ours- 这可以解析任意数量的头，但合并的结果始终是当前的分支头。它旨在用于取代侧分支的旧开发历史。

• subtree- 这是一种改进的递归策略。当合并树A和B时，如果B对应于A的子树，则首先调整B以匹配A的树结构，而不是读取同一级别的树。这种调整也是对共同祖先树进行的。

我什么时候应该指定与默认值不同的内容？每种方案最适合什么场景？

我不熟悉解决方案，但我使用过其他的：

递归

递归是非快进合并的默认设置。我们都很熟悉那个。

Octopus

当我有几棵树需要合并时，我使用了章鱼。您可以在大型项目中看到这一点，其中许多分支都进行了独立开发，并且准备好整合到一个头中。

章鱼分支会在一次提交中合并多个头，只要它能够干净地完成即可。

为了便于说明，假设您有一个项目，它有一个主项目，然后有三个要合并的分支（称为 a、b 和 c）。

一系列递归合并看起来像这样（请注意，第一次合并是快进，因为我没有强制递归）：

然而，单个章鱼合并看起来像这样：

commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...

Ours

我们的 == 我想引入另一个 head，但丢弃该 head 引入的所有更改。

这保留了分支的历史记录，而没有分支的任何影响。

（阅读：甚至没有查看这些分支之间的更改。分支只是合并，并且对文件没有执行任何操作。如果您想合并其他分支并且每次都会出现“我们的文件版本或它们的文件版本”的问题版本”您可以使用git merge -X ours)

Subtree

当您想要将另一个项目合并到当前项目的子目录中时，子树非常有用。当您不想将库作为子模块包含时很有用。