在开发过程中使用git rebase还是git merge,优缺点分别是什么?

关注者
661
被浏览
63,465
两个使用场景是不一样的,merge只是合并另外一个分支的内容,rebase也合并另外一个分支的内容,但是会把本分支的commits顶到最顶端

假设我们现在有3个分支
  1. master分支:线上环境使用的分支
  2. testing分支:测试环境使用的分支
  3. my_feature分支:开发新功能的分支,也就是当前分支
A. 假设我在my_feature上开发了一段时间,之后另外的同事开发的功能正式上线到master分支了,那么我可以在当前的分支下rebase一下master分支,这样我这个分支的几个commits相对于master还是处于最顶端的,也就是说rebase主要用来跟上游同步,同时把自己的修改顶到最上面

B. 我在my_feature上开发了一段时间了,想要放到testing分支上,那就切到testing,然后merge my_feature进来,因为是个测试分支,commits的顺序无所谓,也就没必要用rebase (当然你也可以用rebase)


另外,单独使用rebase,还有调整当前分支上commits的功能(合并,丢弃,修改commites msg)

PS:
其他知友的答案都说到冲突的问题,

1. 用merge确实只需要解决一遍冲突,比较简单粗暴
2. 用rebase有时候会需要多次fix冲突(原因在于本地分支已经提交了非常多的commit,而且很久都没有和上游合并过)

我个人推荐大家开发的时候,尽量及时rebase上游分支(我习惯是每周merge一次),有冲突提前就fix掉,即使我们自己的分支开发了很久(哪怕是几个月),也不会积累太多的conflict,最后合并进主分支的时候特别轻松, 非常反对从master check出新分支,自己闷头开发几个月,结果最后merge进主分支的时候,一大堆冲突,自己还嗷嗷叫的行为