Rebase和Merge操作最终的结果是一样的，但是实现原理不一样。
从上面的MairoBro例子可以知道pull大概对历史记录进行了怎样的合并操作，其实默认pull的操作就是一个分支的merge操作，如下图重现一下：
Mairo弟弟的提交记录如下：
Mairo哥哥的提交记录如下：
首先是Mairo弟弟把更新push到服务器，这样服务器端的记录就和Mairo弟弟本地的记录是一样的，接着Mairo哥哥执行pull操作，现在分析下pull是如何操作的。
l pull默认就是先把服务器端的最新记录更新到本地的Remote Tracking中对应的mirror分支
l 接着对Local的mirror分支和Remote Tracking的mirror分支进行merge操作
Merge操作后的结果就是会新增加一个merge记录节点，如下所示：
从上图可以看出，mushroomA是在mushroomB之前的，这个时间关系不取决于谁先执行push，而取决于本地仓库中谁先执行commit。所以merge会按照时间顺序严格的记录每一次commit。
接下来看看rebase，其实rebase也是把两个分支进行合并的操作，当Mairo弟弟push更新后，服务器端的mirror分支的历史如下：
Mairo哥哥本地的历史如下：
现在Mairo哥哥不是执行merge操作，而是执行rebase操作，最后结果如下：
很明显的区别是没有出现分支的记录，而且注意到mushroomA*，请注意这个记录和mushroomA不是同一个记录，我们先分析下rebase操作下，Mairo哥哥的历史记录都做了哪些变化：
l 先将当前分支的更新部分保存到临时区域，而当前分支重置到上一次pull的记录
l 然后将服务器端的更新添加到当前分支，此时当前分支和服务器端分支是一样的
l 最后将原分支的更新部分mushroomA提交到当前分支的后面，就是要在mushroomB的后面添加mushroomA的更新，当然此时更新记录已经不是之前的mushroomA了，如果出现冲突则使用对比工具解决冲突，最后记录变成mushroomA*。
如果Mairo哥哥提交过mushroomA1、mushroomA2、mushroomA3，那么执行rebase后会对mushroomA1、 mushroomA2、mushroomA3分别顺序执行上图所示的合并，最后记录为mushroomA1*、mushroomA2*、 mushroomA3*。很显然rebase操作更复杂，冲突的概率也更高，并且不是按照时间顺序记录。
