阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7001409038307033119 「Will_Liao」欢迎转载，保留摘要，谢谢！

• git merge 和 git rebase的区别
• git merge
• git rebase
• 总结

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

git merge 和 git rebase的区别

目的都是将一个分支的 commit 合并到到另外一个分支中去。

git merge

1. 在gitlab上新建一个项目，push一个test文件上去

2. 在本地修改test文件做两次commit，每次commit都在文件中加一句修改

3. 在远程仓库中直接修改文件并 commit，模拟其他开发者的 commit。

4.如果此时我push本地的提交到远程，就会被拒绝，因为远程和本地已经各自有commit了，我们常规的做法是git pull一下，在本地解决冲突，然后继续push，本质上git pull = git fetch + git merge。

产生冲突：

处理冲突：

重新走add commit 然后push，可以看到必须将合并当作一个新的commit：

git rebase

如果我们此时采用git pull --rebase，也就是=git fetch + git rebase。

1. 一样本地commit2次，远程commit2次

2. 使用可以看到git pull --rebase，还是会提示我们去处理冲突，但是从git log 上可以看出明显已经发生了rebase，也就是变基，本地分支基于了远程的最新commit，而不是上次的本地commit。

3. 处理冲突，每处理完一次本地commit冲突，用git add标记冲突已处理完，用git rebase --continue继续处理下一个本地commit，也可以先用git rebase -i将本地的commit合并为一个commit，这样git pull --rebase就能一次处理所有的冲突。

4. push到远程之后，在分支图可以明显看到，跟merge的区别在于，rebase不会产生分支，并且也不会产生新的提交。

总结

• merge 是一个合并操作，会将两个分支的修改合并在一起，默认操作的情况下会提交合并中修改的内容。
• merge 的提交历史记录了实际发生过什么，关注点在真实的提交历史上面。
• rebase 并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的最新提交后面。
• rebase 操作会丢弃当前分支已提交的 commit，故不要在已经 push 到远程，和其他人正在协作开发的分支上执行 rebase 操作。
• merge 与 rebase 都是很好的分支合并命令，没有好坏之分，使用哪一个应由团队的实际开发需求及场景决定。
• 如果比较关注commit时间的话，还是用git merge，rebase会打乱时间线是不可避免的。