用了这么久的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上提交时可以使用,说白了就是将其当做一个子模块一般。