1.变基的基本操作
在Git中整合来自不同分支的修改主要有两种方法：merge和rebase。
看下面的例子：开发任务分叉到了两个不同的分支，并且都有了新的提交。
这时候我们可以使用git merge命令将experiment分支合并进入master分支，Git会将C3、C4以及两者最近的共同祖先做一个三方合并，并且生成一个新的提交。如下图所示：
其实我们还可以使用rebase命令：rebase命令将提交到某一分支上的提交都移至另一个分支上
$ git checkout experiment$ git rebase masterFirst, rewinding head to replay your work on top of it...Applying: added staged command
如下图所示：使用rebase之后，将experiment分支上的提交移动到了master分支的后面。
原理：首先找到两个分支（当前所在分支experiment和目标基底分支master）的最近共同祖先（即C2），然后对比当期分支相对于最近共同祖先的所有提交，提取相应的修改存为临时文件，然后将当前分支指向目标基底（即C3），最后将此前存好的临时文件依次应用（理解为将从当前分支上，从最近共同祖先开始的后一个提交节点，开始复制，放到目标基底后）。
完成rebase操作之后，可以运行以下命令，进行一次快速移动。
$ git checkout master$ git merge experiment
操作完成之后，提交历史如下图所示。
与直接使用merge命令相比，rebase命令可以使提交历史更加的整洁，看上去就像是一条直线。使用rebase的目的是是提交历史看起来更加的整洁，其实，无论是通过merge还是rebase，整合的最终结果都是一样的，只不过rebase的提交历史看起来更加的整洁。rebase是将一系列提交按照原有次序依次应用到另一分支上，而merge是将最终结果merge在一起。
2.rebase VS merge
对于rebase和merge哪种好，有两种观点：
1.有一种观点认为，仓库的提交历史即是记录着实际上发生过什么，它是一种历史文档，本身具有价值，不能随意修改，这些历史应该被保留下来，供后人进行查阅。这种观点支持使用merge而不是rebase。
2.另一种观点正好相反，他们认为提交历史是项目开发过程中发生的事情，没有人会出版一本书的第一版草稿，都是需要进行多次修订之后才能进行出版的，修订之前的这些历史不应该被读者看到。这种观点鼓励使用rebase。
总的原则：只对尚未推送或分享给他人的本地修改执行rebase操作清理历史，从不对已经提交到别处的提交进行rebase操作。
