点击上方“Java基基”，选择“设为星标”
做积极的人，而不是积极废人！
每天 14:00 更新文章，每天掉亿点点头发...
源码精品专栏
来源：juejin.cn/post/
7001409038307033119
git merge 和 git rebase的区别
目的都是将一个分支的 commit 合并到到另外一个分支中去。
“推荐下自己做的 Spring Boot 的实战项目：
https://github.com/YunaiV/ruoyi-vue-pro
git merge
在gitlab上新建一个项目，push一个test文件上去
在本地修改test文件做两次commit，每次commit都在文件中加一句修改
在远程仓库中直接修改文件并 commit，模拟其他开发者的 commit。
4.如果此时我push本地的提交到远程，就会被拒绝，因为远程和本地已经各自有commit了，我们常规的做法是git pull一下，在本地解决冲突，然后继续push，本质上git pull = git fetch + git merge。
产生冲突：
处理冲突：
重新走add commit 然后push，可以看到必须将合并当作一个新的commit：
“推荐下自己做的 Spring Cloud 的实战项目：
https://github.com/YunaiV/onemall
git rebase
如果我们此时采用git pull --rebase，也就是=git fetch + git rebase。
一样本地commit2次，远程commit2次
使用可以看到git pull --rebase，还是会提示我们去处理冲突，但是从git log 上可以看出明显已经发生了rebase，也就是变基，本地分支基于了远程的最新commit，而不是上次的本地commit。
处理冲突，每处理完一次本地commit冲突，用git add标记冲突已处理完，用git rebase --continue继续处理下一个本地commit，也可以先用git rebase -i将本地的commit合并为一个commit，这样git pull --rebase就能一次处理所有的冲突。
push到远程之后，在分支图可以明显看到，跟merge的区别在于，rebase不会产生分支，并且也不会产生新的提交。
总结
merge 是一个合并操作，会将两个分支的修改合并在一起，默认操作的情况下会提交合并中修改的内容。
merge 的提交历史记录了实际发生过什么，关注点在真实的提交历史上面。
rebase 并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的最新提交后面。
rebase 操作会丢弃当前分支已提交的 commit，故不要在已经 push 到远程，和其他人正在协作开发的分支上执行 rebase 操作。
merge 与 rebase 都是很好的分支合并命令，没有好坏之分，使用哪一个应由团队的实际开发需求及场景决定。
如果比较关注commit时间的话，还是用git merge，rebase会打乱时间线是不可避免的。
欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：
已在知识星球更新源码解析如下：
最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例，以及超 6W 行代码的电商微服务项目。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）
扫一扫
390
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
