git rebase。顾名思义，就是又一次定义（re）起点（base）的作用，即又一次定义分支的版本号库状态。
要搞清楚这个东西，要先看看版本号库状态切换的两种情况：
-
我们知道，在某个分支上。我们能够通过git reset。实现将当前分支切换到本分支曾经的不论什么一个版本号状态，即所谓的“回溯”。
即实现了本分支的“懊悔药”。也即版本号控制系统的初衷。
-
还有还有一种情况，当我们的项目有多个分支的时候。
我们除了在本地开发的时候可能会“回溯”外，也经常会将和自己并行开发的别人的分支改动加入到自 己本地来。这样的情况下非经常见。作为项目管理员，肯定会不断的合并各个子项目的补丁，并将最新版本号推送到公共版本号库，而作为开发者之中的一个。提交自己的补丁之 后，往往须要将自己的工作更新到最新的版本号库，也就是说把别的分支的工作包括进来。
举个样例来说吧。如果我们的项目初期仅仅有一个master分支。然后分支上作过两次提交。这个时候系统仅仅有一个master分支，他的分支历史例如以下：
master0（初始化后的版本号）
||
v
master1（第一次提交后的版本号）
||
v
master2（第二次提交后的版本号）
这个时候，我们能够通过git reset将master分支（工作文件夹、工作缓存或者是版本号库）切换到master1或者master0版本号。这就是前面所说的第一种情况。
如果我们这里把master分支通过git reset回溯到了master1状态。那么这个时候系统仍然仅仅有一个master分支，分支的历史例如以下：
master0（初始化后的版本号）
||
v
master1（第一次提交后的版本号）
然后，我们在这里以master1为起点，创建了还有一个分支test。那么对于test分支来说，他的第一个版本号test0就和master1是同一个版本号。此时项目的分支历史例如以下：
master0（初始化后的版本号）
||
v
master1（第一次提交后的版本号）===test0（test分支，初始化自master分支master1状态）
这个时候，我们分别对master分支、test分支作两次提交，此时版本号库应该成了这个样子：
master0（初始化后的版本号）
||
v
master1===test0==>test1===>test2
||
v
master2===>master3
- 这个时候，通过第一种git reset的方式，能够将master分支的当前状态（master3）回溯到master分支的master0、master1、master2状态。 也可已将test分支当前状态（test2）回溯到test分支的test0、test1状态。以及test分支的父分支master的master0、 master1状态。
-
那么。假设我要让test分支从test0到test2之间全部的改变都加入到master分支来，使得master分支包括test分支的全部改动。
这个时候就要用到git rebase了。
首先，我们切换到master分支。然后执行以下的命令，就可以实现我们的要求：
| git rebase test |
这个时候。git做了些什么呢？
- 先将test分支的代码checkout出来。作为工作文件夹
- 然后将master分支从test分支创建起的全部改变的补丁。依次打上。假设打补丁的过程没问题，rebase就搞定了
-
假设打补丁的时候出现了问题，就会提示你处理冲突。
处理好了，能够执行git rebase –continue继续直到完毕
- 假设你不想处理，你还是有两个选择，一个是放弃rebase过程（执行git rebase –abort），还有一个是直接用test分支的代替当前分支的（git rebase –skip）。