何时使用不一样的git merge策略？

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

• resolve-使用三路合并算法只能解析两个头（即当前分支和从中拉出的另外一个分支）。 它试图仔细检测纵横交错的歧义，而且一般被认为是安全且快速的。

• 递归 -这只能使用3向合并算法解析两个磁头。 当能够用于三向合并的公共祖先不止一个时，它将建立公共祖先的合并树，并将其用做三向合并的参考树。 据报道，经过对来自Linux 2.6内核开发历史记录的实际合并提交进行的测试，能够减小合并冲突，而不会引发错误合并。 此外，这能够检测和处理涉及重命名的合并。 当拉或合并一个分支时，这是默认的合并策略。

• 章鱼 -能够解决两个以上的问题，可是拒绝执行须要手动解析的复杂合并。 它主要用于将主题分支头捆绑在一块儿。 拉或合并多个分支时，这是默认的合并策略。

• 咱们的 -能够解析任意数量的头，可是合并的结果始终是当前分支头。 它旨在取代侧支的旧开发历史。

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

何时应该指定不一样于默认值的内容？ 每一个方案最适合什么状况？

---

#1楼

“解决”与“递归”合并策略

递归是当前默认的两头策略，可是通过一番搜索，我终于找到了有关“解决”合并策略的信息。

摘自O'Reilly的《 使用Git的版本控制》 （ 亚马逊 ）（措辞）：

最初，“解决”是Git合并的默认策略。

在交叉合并的状况下，存在多个合并基础的状况下，解决策略的工做方式以下：选择一种可能的合并基础，并但愿得到最佳合并。 实际上，这并不像听起来那样糟糕。 常常发现，用户一直在处理代码的不一样部分。 在这种状况下，Git会检测到它正在合并一些已经存在的更改，并跳太重复的更改，从而避免了冲突。 或者，若是这些微小的更改确实引发冲突，则至少冲突应该易于开发人员处理。

我已经使用“解析”成功合并了树，但默认递归策略失败了。 我已经fatal: git write-tree failed to write a tree错误，而且因为这篇博客文章 （ mirror ），我尝试了“ -s resolve”，该方法有效。 我仍然不肯定为何……可是我认为这是由于我在两棵树上都有重复的更改，并解决了“跳过”它们的问题。

---

#2楼

我对解决方法不熟悉，可是我使用了其余方法：

递归的

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

章鱼

当我有几棵须要合并的树时，我使用了章鱼。 您能够在较大的项目中看到这一点，在该项目中，许多分支机构都具备独立开发能力，而且全部这些都准备好聚集在一块儿​​。

章鱼分支能够一次提交地合并多个头，只要它能够干净地进行便可。

为了举例说明，假设您有一个具备母版的项目，而后合并了三个分支（分别称为a，b和c）。

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

可是，单个章鱼合并将以下所示：

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

咱们的

咱们的==我想另当别论，但抛弃了头脑所带来的全部变化。

这样能够保留分支的历史记录，而不会影响分支。

（阅读：甚至没有看过这些分支之间的变化。这些分支只是合并而对文件不作任何操做。若是要合并到另外一个分支中，而且每次出现“咱们的文件版本或它们的文件版本版本”，您可使用git merge -X ours ）

子树

要在另外一个项目中合并到当前项目的子目录中时，子树颇有用。 当您拥有不想做为子模块包含的库时，此选项颇有用。

---

#3楼

实际上，若是您要放弃分支带来的更改，可是将分支保留在历史记录中，则只有两种策略是咱们的策略；若是要将独立项目合并到超级项目的子目录中，则能够选择子树 （例如“ git”存储库）。

合并两个以上的分支时，会自动使用章鱼合并。 在这里解决问题主要是因为历史缘由，以及当您被递归合并策略的极端状况所打击时。