合并分支的另一种操作git rebase，又翻译成变基
当我们同时在master和develop上做了修改，两个分支线都往前走了
如果这个时候用merge把master分支合并到develop分支，就会是No-fast-foward的合并方式在develop分支上产生一个新的提交
后续我们去review develop分支的代码的时候，会发现以前master分支上的别人提交的commit5 commit6 和develop分支上你提交的的commit7 commit8杂糅到了一块儿，很不方便review你写的代码
但是，如果你想让develop分支历史看起来像没有经过任何合并一样，你可以用 git rebase命令
$ git rebase master
这个命令会把你的develop分支里的每个提交(commit)都取消掉，并且把它们临时保存为补丁(patch)，这些补丁放到了.git/rebase目录中，然后把develop分支更新为最新的master分支，最后把保存的这些补丁应用到develop分支上。
当develop分支更新之后，它会指向这些新创建的提交(commit)，而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection)，这些被丢弃的提交就会删除
如果rebase过程中有冲突，就先解决冲突，然后执行git rebase --continue 继续变基
当我们使用git log来参看commit时，使用git merge和使用git rebase 的commit的顺序会不相同。
假设commit5提交于9:00AM，commit7提交于10:00AM，commit6提交于11:00AM，commit8提交于12:00AM
对于使用git merge来合并所看到的commit的顺序（从新到旧）是：commit9，commit8，commit6，commit7，commit5，commit4，commit3，commit2，commit1
对于使用git rebase来合并所看到的commit的顺序（从新到旧）是：commit8Copy，commit7Copy，commit6，commit5，commit4，commit3，commit2，commit1 其中commit8Copy提交只是commit8提交的克隆，commit7Copy提交只是commit7提交的克隆
我们再通过一个动画看下rebase的过程
想要学习其他开发技术，可关注我微信公众号：
