概念
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 分支所指向的提交是你当前提交（有关 hotfix 的提交）的直接上游，所以 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
