老大手把手教我玩 Git 变基！

本文转载自微信公众号「小鹿动画学编程」，作者小鹿。转载本文请联系小鹿动画学编程公众号。 

最近不咋在状态，一直没有写技术文。今天爬上来主要和大伙儿唠唠 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(变基) 一下，命令如下：

1git pull base dev --rebase 

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

4、我玩坏了的变基

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

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

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

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

1git cherry-pick <commit id> 

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