Git：Rebase和Merge之间的区别

一、merge

merge的原理是找到这两个分支的祖先commit，在两个分支最新的commit进行三方对比合并
例如下图，共同的祖先commit2,master最新commit6，develop最新commit5，merge会基于2，5，6这三个commit进行对比：

1. commit6和commit2对比，如果文件的哈希值不一样，同时commit5和commit2对比，发现一样，说明只有commit6修改了这个文件，这种情况直接合并，不会提示
2. commit6和commit2对比，如果文件的哈希值不一样，同时commit5和commit2对比，哈希值不一样，说明两个分支都对同一个文件修改了，则提示冲突，需要我们手动merge

最后合并完后会生成一个新的commit7

二、rebase

重新基于一个分支上进行commit,就是会把当前分支从祖先的commit后提交的commit都撤销掉，放到一个缓存里面去，然后基于一个分支的后面，把缓存的commit再按顺序一个个新增到这个分支后面
例如上图，在develop分支进行rebase master分支，则会把develop分支上的基于和master共同的祖先分支commit2的后面的commit4,5撤销掉，在master的最新的commit6后面重新增加commit4，5上去,这时候develop相当于在master最新的commit上逐步提交了两个commit4,5 

这里新增了commit4,5，在merge时有可能都会有冲突，这里有可能需要手动merge两次，因为rebase时可能在提交commit4的时候提示冲突一次，在提交commit5的时候又冲突一次

三、merge和rebase的优缺点

• rebase：合并后分支图谱好看，一条线，但合并过程中出现冲突的话，比较麻烦（rebase过程中，一个commit出现冲突，下一个commit也极有可能出现冲突，一次rebase可能要解决多次冲突）；
• merge：合并后分支图谱不好看，一堆线交错，但合并有冲突的话，只要解一次就行了；
• 一般的做法，如果合并分支的共同祖先分支相差一两个或两三个commit的话，就用rebase，毕竟rebase合并后好看，分支图谱明确，
  如果和共同祖先分支相差很多个commit，说明rebase有可能出现多次冲突，合并会很麻烦，这时候就用merge

参考博客：http://t.csdn.cn/2U6au