PHP8.1.21版本已发布
vue8.1.21版本已发布
jquery8.1.21版本已发布

git学习之rebase实例详解

WBOY
WBOY 转载
2022-03-22 18:22:34 1679浏览

本篇文章给大家带来了关于git/" target="_blank">git的相关知识,其中主要介绍了rebase的相关问题,rebase,变基,可以直接理解为改变基底。feature分支是基于master分支的b拉出来的分支,feature的基底是b,希望对大家有帮助。

推荐学习:《Git学习教程

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

一、提交节点图解

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

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

master上有一个新提交M,feature上有两个新提交C和D
在这里插入图片描述
此时切换到feature分支上,执行如下命令,相当于是想要把master分支合并到feature分支(这一步的场景就可以类比为我们在自己的分支feature上开发了一段时间了,准备从主干master上拉一下最新改动)

git checkout featuregit rebase master

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

下图为变基后的提交节点图,解释一下其工作原理:
在这里插入图片描述

  • 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了。(注意,如果master上在B以后没有新提交,那么就还是用原来的B作为基,rebase操作相当于无效,此时和git merge就基本没区别了,差异只在于git merge会多一条记录Merge操作的提交记录)

上面的例子可抽象为如下实际工作场景:张三从B拉了代码进行开发,目前提交了两次,开发到D了;李四也从B拉出来开发了并且开发完毕,他提交到了M,然后合到主干上了。此时张三想拉下最新代码,于是他在feature分支上执行了git rebase master,即把master分支给rebase过来,由于李四更早开发完并合了主干,如此就相当于张三是基于李四的最新提交M进行的开发了。


二、实际git提交示例

按照上面的图解构造了提交记录,如下图所示:(ABM是master分支线,ABCD是feature分支线。这里画成了master变色分叉出来,这不影响理解,知道是表示两个分支两条线即可!)
在这里插入图片描述
此时,在feature分支上执行git rebase master

变基完成以后,ABCD是原来的feature分支线,ABMC’D’是新的feature分支线,ABM是master分支线(没有变化)
在这里插入图片描述


三、推荐使用场景

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

  1. 拉公共分支最新代码的时候使用rebase,也就是git pull -r或git pull --rebase,但有个缺点就是rebase以后我就不知道我的当前分支最早是从哪个分支拉出来的了,因为基底变了嘛。(正因如此,大部分公司其实都不会用rebase,基本统一使用merge,虽然会多出无意义的一条提交记录“Merge … to …”,但至少能知道谁干了什么事)
  2. 往公共分支上合代码的时候,使用merge。(如果使用rebase,那么其他开发人员想看主分支的历史,就不是原来的历史了,历史已经被你篡改了。比如张三和李四从共同的节点拉出来开发,张三先开发完提交了两次然后merge上去了,李四后来开发完rebase上去(注意李四需要切换到主分支,然后执行git rebase,然后再git pull到远端),则李四的新提交变成了张三的新提交的新基底,本来李四的提交是最新的,结果最新的提交显示反而是张三的,就乱套了)

推荐学习:《Git教程

声明:本文转载于:CSDN,如有侵犯,请联系admin@php.cn删除