git rebase详解

本文用最简洁的例子让你快速掌握rebase原理和用法

一、提交节点图解
首先通过简单的提交节点图解感受一下rebase在干什么

两个分支master和feature,其中feature是在提交点B处从master上拉出的分支

master上有一个新提交M,feature上有两个新提交C和D

git rebase详解

 

 

此时切换到feature分支上,执行如下命令,相当于是想要把master分支合并到feature分支

git checkout feature
git rebase master

//这两条命令等价于git rebase master feature

  

下图为变基后的提交节点图,解释一下其工作原理:

git rebase详解

 

 


feature:待变基分支、当前分支
master:基分支、目标分支
官方解释:当执行rebase操作时,git会从两个分支的共同祖先开始提取待变基分支上的修改,然后将待变基分支指向基分支的最新提交,最后将刚才提取的修改应用到基分支的最新提交的后面。

结合例子解释:当在feature分支上执行git rebase master时,git会从master和featuer的共同祖先B开始提取feature分支上的修改,也就是C和D两个提交,先提取到。然后将feature分支指向master分支的最新提交上,也就是M。最后把提取的C和D接到M后面,但这个过程是删除原来的C和D,生成新的C’和D’,他们的提交内容一样,但commit id不同。feature自然最后也是指向D’。

通俗解释(重要!):rebase,变基,可以直接理解为改变基底。feature分支是基于master分支的B拉出来的分支,feature的基底是B。而master在B之后有新的提交,就相当于此时要用master上新的提交来作为feature分支的新基底。实际操作为把B之后feature的提交存下来,然后删掉原来这些提交,再找到master的最新提交位置,把存下来的提交再接上去(新节点新commit id),如此feature分支的基底就相当于变成了M而不是原来的B了。

二、实际git提交示例
按照上面的图解构造了提交记录,如下图所示:(ABM是master分支线,ABCD是feature分支线。这里画成了master变色分叉出来,这不影响理解,知道是表示两个分支两条线即可!)

git rebase详解

 

 

此时,在feature分支上执行git rebase master

变基完成以后,ABCD是原来的feature分支线,ABMC’D’是新的feature分支线,ABM是master分支线(没有变化)

git rebase详解

 

 


三、推荐使用场景
搞来搞去那么多,这其实是最重要的。不同公司,不同情况有不同使用场景,不过大部分情况推荐如下:

拉公共分支最新代码的时候使用rebase,也就是git pull -r或git pull --rebase,但有个缺点就是rebase以后我就不知道我的当前分支最早是从哪个分支拉出来的了,因为基底变了嘛。(如果使用merge,多出无意义的一条提交记录“Merge … to …”)
往公共分支上合代码的时候,使用merge。(如果使用rebase,那么其他开发人员想看主分支的历史,就不是原来的历史了,历史已经被你篡改了)
参考文章:图解 Git 基本命令 merge 和 rebase

其中还有一句解释也很直白,rebase 命令其实关键在于理解「基」,git rebase <基分支>,就是将基分支与当前分支的差异提交(分岔点之后)获取到,然后在「基分支」最新提交点后面将差异提交逐个再次提交,最后将当前分支的 HEAD 指针指向最新的提交点
————————————————
版权声明:本文为CSDN博主「风中一匹狼v」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_42310154/article/details/119004977

上一篇:git rebase简单使用


下一篇:Git命令之不要使用rebase的场景