共计 1200 个字符，预计需要花费 3 分钟才能阅读完成。
作者：Will_Liao\
起源：juejin.cn/post/7001409038307033119
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 会打乱工夫线是不可避免的。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿 (2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4.20w 程序员红包封面，快快支付。。。
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！