Git必知必会基础(11):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用来合并分支,用于将两个或多个分支的代码合并到一个新的或现有的分支中
合并:会产生一个新的合并提交,并且每个分支的历史记录都会保存(不修改提交历史,可以清晰地看到哪些提交是在哪个分支上完成的)
将dev合并到master 1、dev commit 2、切换到master,与origin/master同步 3、git merge dev
优点:合并保留了每个分支的独立性,即使两个分支合并了,它们的提交历史仍然可以追溯到各自的起点
缺点:合并图非线性,如果分支多且合并多,互相交叉,易读性不高
合并前
合并后
95fc216以下是merge的合并图
rebase
作用:git rebase用来变基,就是重新定义(re)起点(base)的作用,即重新定义分支的版本,能实现和merge相同的效果,将一个分支的修改合并到另一个分支上
合并:会将当前分支的提交“挪动”到rebase的目标分支上,使得分支的提交历史变得更加线性;会修改提交历史,因为它将当前分支的提交重新应用到了新的基础上
将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的合并图
__EOF__
本文作者:持之以恒(韧)
关于博主:擅长性能、全链路、自动化、企业级自动化持续集成(DevTestOps)、测开等
面试必备:项目实战(性能、自动化)、简历笔试,https://www.cnblogs.com/uncleyong/p/15777706.html
测试提升:从测试小白到高级测试修炼之路,https://www.cnblogs.com/uncleyong/p/10530261.html
欢迎分享:如果您觉得文章对您有帮助,欢迎转载、分享,也可以点击文章右下角【推荐】一下!
关于博主:擅长性能、全链路、自动化、企业级自动化持续集成(DevTestOps)、测开等
面试必备:项目实战(性能、自动化)、简历笔试,https://www.cnblogs.com/uncleyong/p/15777706.html
测试提升:从测试小白到高级测试修炼之路,https://www.cnblogs.com/uncleyong/p/10530261.html
欢迎分享:如果您觉得文章对您有帮助,欢迎转载、分享,也可以点击文章右下角【推荐】一下!