Git变基操作

首先要清楚一件事变基本质是一次merge，只是rebase之后相对于普通的merge，在主干分支(比如master)上的提交历史更加简洁，只需要查询master分支就可以了解所有分支开发的的提交历史

下面通过比较普通的merge说明其具体原理

普通的一次merge

merge之前

merge过程通过找到两个分支最近的公共祖先(C2)，然后和两个分支的最新版本C4，C3进行一次三方合并，产生C5版本作为两个分支的合并之后的版本结果如下
merge之后

merge过程本身也确实保存了分支的修改信息，但是此时提交历史就不再整洁，比如在experiment上不止进行了一次提交，还有C4.1, C4.2那么这两个版本在merge之后就无法查看对应的提交信息，修改情况这也是rebase产生的原因

rebase过程

rebase之前

执行下面rebase命令之后

$ git checkout experiment
$ git rebase master

它的原理是首先找到这两个分支（即当前分支 experiment、变基操作的目标基底分支 master） 的最近共同祖先 C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件， 然后将当前分支指向目标基底 C3, 最后以此将之前另存为临时文件的修改依序应用。
依序应用表明在分支开发中历次版本都会作为C3之后的版本被记录，就好像在分支开发的过程整个复制到了master分支上，和在master分支上开发效果类似

之后还需要把master分支指针指向前面的最新版本，切换回master分支进行一次快速合并

$ git checkout master
$ git merge experiment

完成以后版本如下所示：

如果分支开发中有C4.1. C4.2也都会出现在master分支的主干历史上，提交历史就会变得非常简洁