git - 你什么时候会使用不同的 git merge 策略？

Question

在 git-merge 的手册页中，有许多您可以使用的 merge 策略。

• 解决 -这只能使用 3 路 merge 算法解决两个头(即当前分支和您从中提取的另一个分支)。它会尝试仔细检测交叉 merge 歧义，通常被认为是安全和快速的。

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

• Octopus -这解决了不止两个头的情况，但拒绝进行需要手动解决的复杂 merge 。它主要用于将主题分支头捆绑在一起。这是 pull 或 merge 多个分支时的默认 merge 策略。

• 我们的 -这解决了任意数量的分支头，但 merge 的结果始终是当前分支头。它旨在用于取代侧分支的旧开发历史。

• 子树 -这是一种改进的递归策略。 merge 树A和B时，如果B对应A的子树，则先调整B匹配A的树结构，而不是读取同级树。这个调整也是对共同祖先树做的。

我什么时候应该指定不同于默认值的内容？每种情况最适合什么情况？

Answer 1

我不熟悉 resolve，但我用过其他的:

递归

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

Octopus

当我有几棵树需要 merge 时，我使用了 Octopus 。您会在大型项目中看到这一点，在这些项目中，许多分支机构都有独立的开发，并且都准备好整合到一个单一的负责人中。

Octopus 分支在一次提交中 merge 多个头，只要它能干净地完成即可。

为了便于说明，假设您有一个项目，该项目有一个母版，然后要 merge 三个分支(分别称为 a、b 和 c)。

一系列递归 merge 看起来像这样(请注意，第一次 merge 是快进的，因为我没有强制递归):

但是，单个 Octopus merge 看起来像这样:

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

我们的

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

这保留了分支的历史，而不受分支的任何影响。

(阅读:它甚至没有看那些分支之间的变化。分支只是 merge 而没有对文件做任何事情。如果你想在另一个分支中 merge 并且每次都有问题“我们的文件版本或他们的版本”，你可以使用 git merge -X ours)

子树

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