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

49次阅读

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

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

正文完
 0