Git自学成才——git merge

概念

git merge 和 git rebase 是使用率很是高的两条指令 本文对git merge的平常使用场景作一个梳理，git rebase请看 Git自学成才——rebase完整版

假设我有一个开发分支dev，有一个主干分支master

关于哪一个分支合并到哪一个分支，不少人会有混淆和困惑。其实，你须要往哪一个分支上面合并，就要切换到哪一个分支

好比，如今要 把dev分支merge到master分支

首先，保证两个分支都是最新的状态

切换到master分支，执行merge操做

git checkout master
git merge dev
复制代码

git merge 命令用于合并指定分支到当前分支

基础

上面是最基本的git merge，git merge默认采用快进（fast-forward）的方式，产生相似以下的log

Updating f42c576..3a0874c
Fast-forward
 index.html | 2 ++
复制代码

何为 快进（Fast-forward）？

在合并的时候，你应该注意到了"快进（fast-forward）"这个词。 因为当前master分支所指向的提交是你当前提交的直接上游，因此 Git 只是简单的将指针向前移动。 换句话说，当你试图合并两个分支时，若是顺着一个分支走下去可以到达另外一个分支，那么 Git 在合并二者的时候，只会简单的将指针向前推动（指针右移），由于这种状况下的合并操做没有须要解决的分歧——这就叫作 “快进（fast-forward）”。

若是merge的时候没有冲突， 没有新的commit节点产生，只是移动分支的指针，来实现merge

若是merge的时候有冲突， 产生相似以下的log

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
复制代码

须要手动解决冲突，而后执行add，再commit

git add index.html 
git commit -m "conflict fixed Your message..."
复制代码

---

实战

基本知识了解完，来看一下实战中的三种操做

无节点merge

不少公司或者组织会大量使用分支，他们不喜欢在master分支看到错综复杂的merge节点，因此他们的要求是无节点的merge（看起来全部的commit都是一条直线），这样的视觉效果清晰可读性很强。

实现无节点merge，实际上是用到merge指令的默认特性——快进（Fast-forward），由于快进方式的merge不会产生节点，只会移动分支的HEAD指针。

问题是，快进的特性是在没有冲突的状况下产生，而执行merge大几率的状况会有不少冲突。这里搭配rebase变基操做更加合适，具体的rebase操做请看 Git自学成才——rebase完整版

完成rebase操做以后，在master分支上执行

git merge dev

...
Fast-forward
...
复制代码

你会在SourceTree里看看master分支已经包含了dev分支的commit，而且是 一条直线

有节点merge

另一些状况，被要求全部的merge操做必需要保留节点

若是merge有冲突，手动解决完冲突后，add 冲突的文件，再commit，这样已经产生了一个merge节点。

若是要求强制产生merge节点，使用 --no-ff 参数告诉merge，咱们不须要快进（no-ff : no fast forward）

git merge --no-ff -m "merged dev" dev
复制代码

这样会产生一个 “merged dev” 的commit节点

单节点merge

在某些状况下，须要咱们的merge只产生一个commit节点

这时，咱们须要压扁参数squash（能够理解为压缩提交），squash和no-ff很是相似，区别是不会保留对合入分支的引用。也就是说，squash把dev分支的代码压缩在一块儿，在master分支只提交一次。

git merge --squash dev
git commit –m "squash dev"
复制代码

这样的操做会在你的master分支上只产生一个"squash dev"节点（包含了dev分支上的多个commit内容）

以上三种merge方式基本涵盖了平常实战的场景，一图以蔽之

更多内容请参考官方手册 Git 分支 - 分支的新建与合并 git-merge