1.变基

• 变基也是将一个分支的代码整合到另外一个分支。跟merge功能类似，但也存在着很大的不同。变基可以把提交线整合得更加是一条直线。

2.基本操作

• 假如有这样一个提交图
  

• 然后我们把dev分支合并到master分支后，结果图为：
  

• 以上是采用正常的merge操作实现的结果。还有另外一种方式，可以将dev上的代码合并到master分支上。那就是变基。变基命令为git rebase。命令如下：

$ git checkout dev
$ git rebase master

• 原理是，先找到两个分支的共同祖先，然后获取这两个祖先后面提交的diff（不同内容），保存为临时文件，然后再创建一个commit，把这些diff进行提交。再把当前的分支指向最新的提交。示例图如下：
• 这时候已经新生成了一个新的commit。并且dev已经指向了这个commit。我们的目的是要把dev分支上的代码合并到master分支上，在这里我们还需要执行merge操作。命令如下：

$ git checkout master
$ git merge dev

到现在为止，我们通过merge和rebase得到的结果都是一样的，就是都把代码合并到master分支上了。

不管是变基操作后最新的提交，还是合并操作后最终的合并提交，这两个提交的快照内容是完全一样的，这两种操作的结果区别只是得到的提交历史不一样。总结一下，变基操作是把某条开发分支线上的工作在另一个分支线上按顺序重现。而合并操作则是找出两个分支的末端，并把他们合并到一起。

3.解决冲突

• 在产生冲突的时候，我们先解决冲突。然后做一个git add .，
• 接着再执行git rebase --continue操作，
• 再回退到master分支，执行git merge dev操作。

4.什么时候使用变基

• 1.看公司的策略。有的公司认为提交历史就是实际发生过的事件的记录。它是一个记载着历史的“史书”，自有其价值，而且不能随意篡改。从这个角度来说，是不允许更改提交历史，也就不能使用变基了。

• 2.还有另外一个角度是，提交历史是关于项目如何被构建的故事。就像我们写的软件，一定是整理好了才发出去，使得后来的人能够更好的理解项目的构建。这时候就推荐使用变基。

5.注意事项

千万不要在协作的分支上（比如dev/master）上使用变基，否则会变得非常乱！

我们可以在自己的分支上，把代码变基到协作分支上，这样既不影响和别人的协作，也可以让自己的分支更加的简洁（也要看自己的喜好）。