在 git 中整合来自不同分支的修改主要有两种方法：合并（merge）以及 变基（rebase）

merge流程图

merge的原理是找到这两个分支的祖先commit，在两个分支最新的commit进行三方对比合并。

注：git会对每个文件进行一个哈希计算，这个值一样的话说明文件没有改动过

上图中，共同的祖先commit2,master最新commit6，develop最新commit5，merge会基于2，5，6这三个commit进行对比

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

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

变基（rebase）

上图的另一种合并方法：在develop分支上提取出commit4,5的修改，然后在master的最新的commit6的基础上应用commit4,5的修改，这种方式就是变基（rebase）。你可以使用 rebase命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。

rebase结果

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

总结

• rebase：合并后分支图谱好看，一条线，但合并过程中出现冲突的话，比较麻烦（rebase过程中，一个commit出现冲突，下一个commit也极有可能出现冲突，一次rebase可能要解决多次冲突）；
• merge：合并后分支图谱不好看，一堆线交错，但合并有冲突的话，只要解一次就行了；

一般多人合作的时候优先考虑合并，一个人玩的时候可以用变基。

,