git rebase详解

git rebase是什么？

什么是变基？
将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。

git rebase原理

首先找到这两个分支的最近共同祖先，然后对比当前分支相对于该分支的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标基地，最后以此将之前另存为临时文件的修改依序应用。

git rebase的用途

1.合并多次提交（git rebase -i）

git rebase -i HEAD~4 (合并最近的4次提交)

2.分支合并

git rebase和git merge的区别

git merge

这种合并是将两个分支的历史合并到一起，现有的分支不会被更改，它会比对双方不同的文件缓存下来，生成一个commit。
优点：安全，现有分支不会被修改；
缺点：生成一个merge的commit，会污染提交历史，在回看项目时会增加理解项目历史的难度；
用途：一般用于公共的master主分支；

git rebase

这种合并通常称之为“衍合”，会修改提交历史
优点：项目历史会非常整洁；
缺点：安全性和可跟踪下较差，你将无法知晓你这次合并做了哪些修改，绝不要在公共分支上使用；
用途：自己本身独立使用的分支

总结：硬币都有两面，两种提交方式各有优缺点。在我们自己持有的分支，使用git rebase的方式合并代码，保持提交记录整洁；在公共分支上，使用git merge方式合并，安全并且容易跟踪修改。

举个例子：
1.我们先从master分支切出一个feature1分支进行新功能的开发；

git:(master) git checkout -b feature1

提交树.png

2.这个时候你同事完成了一次hotfix，并合并进master，此时master分支已经领先于你的feature1分支了；

图片.png

3.我们的新功能开发完毕，想合并到master分支，首先想到了merge；

git:(feature1) git merge master

图片.png

途中蓝色的点就是我们合并过后的提交，可以到merge后生成了一个新的合并commit，这也是前面讲到的会污染commit记录的情况。
4.我们回退到第二步，使用git rebase来合并；

git:(feature1) git rebase master

图片.png

rebase执行过程：
首先，git会把feature1分支里面的commit取消掉；
其次，把上面的操作临时保存为patch文件，存在.git/rebase目录下；
然后，把feature1分支更新到最新的master分支；
最后，把上面保存的patch文件应用到feature1分支上；

合并完成后是一个线性的提交记录，不会生成merge的commit的记录，看着很舒服。

注：
1.在rebase的过程中，也许会出现冲突conflict。在这种情况，git会停止rebase并让你去解决冲突。在解决完冲突后，用git add命令去更新这些内容。无需执行git commit，只需执行git rebase --continue,这样git会继续应用余下的patch补丁文件。
2.在任何时候，都可以用git rebase --abort命令来终止rebase的行动，并且分支会回到rebase开始前的状态。