Git必知必会基础（11）：merge和rebase的区别

阅读目录

• merge和rebase使用回顾
• merge
• rebase

 

本系列汇总，请查看这里：https://www.cnblogs.com/uncleyong/p/10854115.html

回到顶部

merge和rebase使用回顾

上两篇我们分别演示了merge和rebase的使用，分别详见：

https://www.cnblogs.com/uncleyong/p/17967432

https://www.cnblogs.com/uncleyong/p/17978213

下面我们来总结下二者的差异。

 

回到顶部

merge

作用：git merge用来合并分支，用于将两个或多个分支的代码合并到一个新的或现有的分支中

 

合并：会产生一个新的合并提交，并且每个分支的历史记录都会保存（不修改提交历史，可以清晰地看到哪些提交是在哪个分支上完成的）

?

1 2 3 4 5 6 7

将dev合并到master   1、dev commit   2、切换到master，与origin/master同步   3、git merge dev

　　

 

优点：合并保留了每个分支的独立性，即使两个分支合并了，它们的提交历史仍然可以追溯到各自的起点

 

缺点：合并图非线性，如果分支多且合并多，互相交叉，易读性不高

 

合并前

 

合并后

 

95fc216以下是merge的合并图

 

回到顶部

rebase

作用：git rebase用来变基，就是重新定义（re）起点（base）的作用，即重新定义分支的版本，能实现和merge相同的效果，将一个分支的修改合并到另一个分支上

 

合并：会将当前分支的提交“挪动”到rebase的目标分支上，使得分支的提交历史变得更加线性；会修改提交历史，因为它将当前分支的提交重新应用到了新的基础上

?

1 2 3 4 5 6 7 8 9

将dev合并到master   1、dev commit   2、切换到master，与origin/master同步   3、切换到dev，git rebase maser，如果有冲突就修改冲突文件，git rebase --continue   4、切换到master，git merge dev

　　

优点：git rebase 对两个分叉的分支合并后，历史记录是一条直线（线性），会显得更为整洁，合并图更易读

 

缺点：由于 rebase 将提交历史变得线性，所以在 rebase 后，你无法直观地看出哪些提交是在原分支上完成的，可能会丢失分支的独立性

 

另外：

1、不要对master分支进行rebase

2、仅对本地自己的提交且没有推送到远程仓库的分支做rebase操作

 

 

合并前

 

合并中

 

合并后

 

95fc216以上是rebase的合并图

 

【bak】