最近不咋在状态，一直没有写技术文。今天爬上来主要和大伙儿唠唠 GIT 的变基模式(rebase)。
本篇文章是基于有一定 GIT 基础的，如果没接触过，可以看之前写的两篇入门文章。
动画：扫盲 Git 版本控制(上)
动画：扫盲 Git 版本控制（下）
第一次在团队合作项目中用到和学习到变基模式，是老大教科书般手把手教我的，通过项目中的不断运用，总结出一些自己的使用和看法。
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？
小结
Git 变基完全理解了之后，感觉不是特别难，但是前期刚接触，确实很多不太明白的地方，导致玩坏了很多次。话说回来，不经历风雨，怎么见彩虹呢？