本文转载自微信公众号《小鹿动画学习编程》，作者小鹿。转载本文请联系小鹿动漫学习编程公众号。最近状态不太好，也没写什么技术文章。今天爬上去主要是和大家聊聊GIT的变基模式（rebase）。这是我第一次在团队项目中使用和学习rebase模式。老板像教科书一样教我。通过在项目中不断的使用，自己总结了一些自己的使用方法和看法。一些初学者对GIT本身并不是很了解。就我个人而言，一些基本概念在刚接触的时候并没有完全理解。只有当我把这些概念付诸实践，形成自己的理解时，我才能知道这个概念原来是这个意思，这个命令长这个样子。所以小鹿尽量多画图，减少废话，让对GIT没有深入了解的朋友提供一些帮助。1.什么是变基？rebase可以理解为低基数的意思。就像盖楼一样，一层一层往上盖，底层是地基。我们称建筑物的每一层为地基。（为了便于理解，以上楼为例）假设，我们的楼是建的，一共18层，需要多个装修工去每一层装修。我的装修组一共有三个人，分别是A、B、C，A负责第一层，B负责第二层，C负责第三层。按照正常的逻辑，提前装修完自家楼层的三人会去四楼装修。但是有个问题，如果B的二楼装修也完成了，但是B不知道另外两个人的最新进度，所以他需要通过某种方式将自己当前的进度更新到最新（B应该知道下一步装修第一层）几层），才能根据另外两层的进度继续装修。虽然上面建楼的例子不太适合项目中的团队合作使用GITrebase，为了让大家先有个大概的印象。2、为什么要用rebase？一般情况下，我们团队协同工作，使用GIT版本控制。每个人都在自己的分支上开发。最后，负责人将各人开发的分支合并（merge）到总分支。另一个变化发生了。基本模式，它是做什么用的？首先，项目变大了，团队成员变多了，提交的分支也越来越多，大家commit后要合并到主分支。整个git分支图看起来很乱，不利于维护和管理。（如上图所示）其次，项目充满了各种commit。如果哪天，发生了紧急事件，需要回滚代码，发现大量的commit需要一个一个地读取，这样就看到人生疑惑了。以上两个原因完全可以让我放弃传统的提交合并，使用rebase方式提交的代码异常清晰。（如下图所示）3.如何变基？对于如何rebase，这部分最重要的是练习，练习，再练习。没有实践，看书也没用，记住我说的。在rebase模式下，使用了以下常用命令，以上述搭建为例。当第二层B完成后，它想知道后面几个人的开发进度，然后根据每个人的进度进行下一步的开发。就像在项目中，我想提交我开发的功能，但是我开发当前功能的时候，可能远程仓库里已经有人提交了代码，导致我本地仓库和远程仓库的代码不一致。在推送代码之前要实现和远程仓库代码一样的代码，我们需要变基（rebase），命令如下：1gitpullbasedev--rebase这条命令相当于，B直接到了五楼用于装饰。而我们的改造记录，也就是我们的开发主支，已经变得非常清晰明了，是一条充满commit的支线。4.我rebase玩的不好，但是问题来了。前期刚开始使用GITrebase模式的时候，玩坏了很多次，总结了一些经验。我每次提交最新代码的时候，每次都忘记rebase，也就是每次都没有考虑到最新的remote代码，而是开发功能直接提交，导致线上代码出现fork（其实就是回到原来的提交方式）。我很着急，我该怎么办？老大一会出去，一会带二，没毛病。使用rollback和pick让主分支不再fork。所谓pick就是使用cherry-pick命令将commit提交重新attach到你要挂载的分支上。1gitcherry-pick
