git进阶之--merge的5种策略

用了这么久的git，其中很长一段时间都是属于，瞎几把乱用。对于git merge这些东西用的也是只知道个大概。同事最近给我们安利了一发git merge的侧率，大开眼界，记录一发。

上网百度了一下git策略，在网上，大多数的git侧率都是只有3种的。这次我所要记录的，是5种策略。

常规合并里分为三种:

解决（Resolve）
递归（Recursive）
章鱼（Octopus）

非常规两种:

我们的（Ours）
子树（Subtree）

在看策略之前，我们先看看关于merge在做处理时候的参数
主要分为三种：

--ff  --ff--only  快速合并    只快速合并（如果有冲突就失败）
--no-ff   非快速合并
--squash  将合并过来的分支的所有不同的提交，当做一次提交，提交过来

--ff和--no-ff的区别是，当解决完冲突后，no-ff会生成一次commit
eg: Merge branch 'suit' into master

好的现在来详细的看一看各种策略

首先看一下最基本的
**解决（Resolve）**：
这种策略只能合并两个分支，首先定义某个次commit为祖先为合并基础，然后执行一个直接的三方合并

**递归（Recursive）**：
和解决很相似，说白了就是多次的调用解决。为什么会有这个策略呢？因为解决策略，是找到两个分支的某个commit为组向才来合并的，如果某一个分支上，某一次提交（祖先或者祖先以后的提交）是merge过的，这时候，就需要递归来解决了。

**章鱼（Octopus）**：
当需要多个分支的时候，就可以用octopus来解决，这就是来同时合并多个分支的策略。

再看看特殊的策略
**我们的（Ours）**：
这是一个很奇怪的策略，我感觉没啥用，不知道其用途是如何
它的作用是，将另外一个分支的commit记录（log）提交过来，但是不提交文件本身。

**子树（Subtree）**：
这种策略是在用于，当想将一个新的项目作为该项目的子项目往git上提交时可以使用，说白了就是将其当做一个子模块一般。