作者：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开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞+转发哦！
发表回复