首页 资讯频道 互联频道 智能频道 网络 数据频道 安全频道 服务器频道 存储频道

什么是变基?详解GIT变基模式(rebase)

2020-10-15 08:27:31 来源 : 小鹿动画学编程

最近不咋在状态,一直没有写技术文。今天爬上来主要和大伙儿唠唠 GIT 的变基模式(rebase)。

第一次在团队合作项目中用到和学习到变基模式,是老大教科书般手把手教我的,通过项目中的不断运用,总结出一些自己的使用和看法。

GIT 本身对于一些初学者理解的不是这么好,对我个人来说,一开始一些基本概念在刚接触的时候,并不能通透的理解,只有当将这些概念放到实践形成自己的理解,才能知道这个概念原来是这个意思,以及这个命令是这个样子的。

所以,小鹿尽可能的多画图,少废话,便于对 GIT 理解不够透彻的朋友能够提供一些帮助。

1、什么是变基(rebase)

变基,我们可以理解为基低的意思。就像盖楼一样,一层层的向上盖,最下面是地基,我们把盖的每一层称为基。

(为了更好的理解,就拿上述盖楼为例)

假如,我们的楼层盖好了,共18层,需要多个装修工去每一层进行装修。我的装修团队一共有三个人,分别为A、B、C。

A 负责第一层,B 负责第二层,C 负责第三层。按照正常的逻辑,三个人谁提前装修完自己的那一层,谁就要到第四层进行装修。

但是有个问题就是,假如 B 第二层也装修完毕,但是 B 不知道其他两个人的最新进度,所以需要通过某种方式,把自己当前的进度更新到最新(B 应该知道下一步该装修第几层),才能继续在其他两人的进度基础上继续装修。

以上盖楼的例子虽然不是太符合项目中团队合作使用 GIT 变基,为了让大伙儿先有个大体的印象。

2、为什么使用变基?

一般我们团队合作使用 GIT 版本控制,每个人在自己分支上开发,最后负责人把每个人开发的分支 merge(合并) 到总分支上就可以了,又出了个变基模式,是干嘛的?

其一,项目变大了,团队的人员变多了,提交的分支越来越多,而且每个人 commit 之后都要合并到主分支,整个 git 分支图看起来烂七八糟,不利于维护和管理。(如上图所示)

其二,项目中充斥着各种各样的 commit ,如果有一天,出现了紧急的事件,需要回滚代码,发现这大量的 commit 需要一条条的看,让你看到怀疑人生。

以上两个理由完全可以让我放弃传统的提交合并,使用变基模式提交的代码就显的格外的清晰。(如下图)

3、如何变基?

对于如何变基,这部分最重要的是需要去实践、实践、实践。没有实践,看了也白看,记住我说的。

变基模式,用到了以下几个常用命令,还是以上述的盖楼为例。

当 B 第二层盖完的时候,它想要得知以下大家的开发进度,然后在大家进度的基础上进行接下来的开发。

就犹如在项目中,我要提交我开发完的功能,但是我开发当前功能的时候,远程仓库中可能有别人已经提交过代码了,导致了我本地仓库和远程仓库代码不一致。

想要在 push 代码前达到与远程仓库代码一致,我们需要 rebase(变基) 一下,命令如下:

1gitpullbasedev--rebase

这个命令的相当于,B 直接到达了楼层的第五层进行装修。而且我们的装修记录,也就是我们的开发主分支变的非常的清晰和明确,就是一条挂满 commit 的分支线。

4、我玩坏了的变基

但是问题来了,GIT 变基模式前期刚使用的时候,被我多次玩坏,总结出了一些经验。

当我每次提交最新代码的时候,每次忘记 rebase,也就是每次没有顾及到远程的最新代码,而是开发完功能,直接进行提交,导致线上的代码出现分叉(其实又回到了原来的提交方式)。

很着急,该咋办?老大出马,一个顶俩,没毛病。

使用回滚和 pick 的方式,让主分支不再出现分叉。所谓的 pick 是使用 cherry-pick 命令将 commit 的提交重新挂在到你想要挂载的分支上。

1gitcherry-pick

当你 pick 完之后,再重新进行 push 和 pr,分叉的分支就回到了原来的一条线上。是不是很 nice?

小结

Git 变基完全理解了之后,感觉不是特别难,但是前期刚接触,确实很多不太明白的地方,导致玩坏了很多次。话说回来,不经历风雨,怎么见彩虹呢?

关键词:变基 GIT变基
相关文章

最近更新