关于java:合并代码还在用-git-merge我们都用-git-rebase

作者: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开发手册(嵩山版)》最新公布,速速下载!

感觉不错,别忘了顺手点赞+转发哦!

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理