git 合并代码之--merge、rebase

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

它的原理是回到两个分支（你所在的分支和你想要衍合进去的分支）的共同祖先(base)，提取你所在分支(develop)每次提交时产生的差异（diff），把这些差异分别保存到临时文件里，然后从当前分支转换到你需要衍合入的分支(master)

合并后的 Develop2（即现在的 Develop2`）所指的快照，同上面Merge三方合并例子中的 Merge所指的快照内容一模一样了。最后整合得到的结果没有任何区别，但衍合能产生一个更为整洁的提交历史。如果视察一个衍合过的分支的历史记录，看起来更清楚： 仿佛所有修改都是先后进行的，尽管实际上它们原来是同时发生的。

---

总结

git rebase过程相比较git merge合并整合得到的结果没有任何区别，但是通过git rebase衍合能产生一个更为整洁的提交历史。
如果观察一个衍合过的分支的历史提交记录，看起来会更清楚：仿佛所有修改都是在一根线上先后完成的，尽管实际上它们原来是同时并行发生的。

一般我们使用衍合的目的，是想要得到一个能在远程分支上干净应用的补丁，比如某个项目你不是维护者，但是想帮点忙，最好使用衍合处理。
先在自己的一个分支进行开发，当准备向主项目提交补丁的时候，根据最新的orgin/master进行一次衍合操作然后再提交，这样维护者就不需要任何整合工作。

实际为：把解决分支补丁同最新主干代码之间的冲突的责任，划转给由提交补丁的人来解决。
作为维护项目的人只需要根据你提供的仓库地址做一次快进合并，或者直接采纳你提交的补丁。

衍合的风险，请务必遵循如下准则：
一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。