git最常用方法之一，合并代码，大部分时候我们都是使用merge命令。其实还有rebase命令，既然都是合并代码，两者有什么差异和共同点？
那就来深入了解一下
1.相同点
虽然git合并代码有merge和rebase两种方式，但是两种合并方式的最终结果是一样的，没有任何区别。
既然整合结果没有区别，那么区别在哪了？那就是合并过程。
2.不同点
以两个分支为例，主分支master，新分支develop，将develop分支合并到master主分支
2.1. merge合并
//当前处于master分支
daideMacBook-Pro:UIFinalTest dai$ git status
On branch master
Your branch is ahead of 'github/master' by 5 commits.
(use "git push" to publish your local commits)
//创建并切换到develop分支
nothing to commit, working tree clean
daideMacBook-Pro:UIFinalTest dai$ git checkout -b develop
Switched to a new branch 'develop'
//创建一个类,添加到develop仓库
daideMacBook-Pro:UIFinalTest dai$ git add .
daideMacBook-Pro:UIFinalTest dai$ git commit -m'Develop1'
[develop 905f008] Develop1
Committer: dai <dai@daideMacBook-Pro.local>
//切换到master分支，并添加一个类到master仓库
daideMacBook-Pro:UIFinalTest dai$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'github/master' by 5 commits.
(use "git push" to publish your local commits)
daideMacBook-Pro:UIFinalTest dai$ git add .
daideMacBook-Pro:UIFinalTest dai$ git commit -m'Master1'
[master 4d82b67] Master1
Committer: dai <dai@daideMacBook-Pro.local>
//再次添加一个类到master仓库
daideMacBook-Pro:UIFinalTest dai$ git add .
daideMacBook-Pro:UIFinalTest dai$ git commit -m'Master2'
[master 3a2c545] Master2
Committer: dai <dai@daideMacBook-Pro.local>
//最后，再回到develop分支，添加一个类到develop仓库
daideMacBook-Pro:UIFinalTest dai$ git checkout develop
Switched to branch 'develop'
daideMacBook-Pro:UIFinalTest dai$ git add .
daideMacBook-Pro:UIFinalTest dai$ git commit -m'Develop2'
[develop 78d53bf] Develop2
Committer: dai <dai@daideMacBook-Pro.local>
因为master和develop的父分支是一样的，都是base，所以具体流程如下：
master： base <--- Master1 <--- Master2
develop： base <--- Develop1 <--- Develop2
合并代码：
//先切换到master分支，使用git merge develop命令
daideMacBook-Pro:UIFinalTest dai$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'github/master' by 7 commits.
(use "git push" to publish your local commits)
daideMacBook-Pro:UIFinalTest dai$ git merge develop
因为使用merge命令是按照时间戳先后顺序的，所以，得到的提交历史为：
base <--- Develop1 <--- Master1 <--- Master2 <---Develop1 <--- Merge(做了三方合并发现冲突，手工处理冲突后git add/commit增加了提交节点Merge)
2.2 rebase合并
分支创建同上，但是在合并代码时，不需要切换到master分支
合并代码：
daideMacBook-Pro:UIFinalTest dai$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Develop1
Applying: Develop2
1：回到两个分支（master、develop）的共同祖先(base)，
2：提取你所在分支(develop)每次提交时产生的差异，
3：把这些差异分别保存到临时文件里，
4：然后从当前分支(develop)转换到你需要衍合的分支(master)，
5：依照顺序把分支master的差异commit放到分支feature-1中。
合并后的 Develop2（即现在的 Develop2`）所指的快照，同上面Merge三方合并例子中的 Merge所指的快照内容一模一样了。最后整合得到的结果没有任何区别，但衍合能产生一个更为整洁的提交历史。如果视察一个衍合过的分支的历史记录，看起来更清楚： 仿佛所有修改都是先后进行的，尽管实际上它们原来是同时发生的。
总结
git rebase过程相比较git merge合并整合得到的结果没有任何区别，但是通过git rebase衍合能产生一个更为整洁的提交历史。
如果观察一个衍合过的分支的历史提交记录，看起来会更清楚：仿佛所有修改都是在一根线上先后完成的，尽管实际上它们原来是同时并行发生的。
一般我们使用衍合的目的，是想要得到一个能在远程分支上干净应用的补丁，比如某个项目你不是维护者，但是想帮点忙，最好使用衍合处理。
先在自己的一个分支进行开发，当准备向主项目提交补丁的时候，根据最新的orgin/master进行一次衍合操作然后再提交，这样维护者就不需要任何整合工作。
实际为：把解决分支补丁同最新主干代码之间的冲突的责任，划转给由提交补丁的人来解决。
作为维护项目的人只需要根据你提供的仓库地址做一次快进合并，或者直接采纳你提交的补丁。
衍合的风险，请务必遵循如下准则：
一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。
