Git的merge和rebase

2019独角兽企业重金招聘Python工程师标准>>>

分支是Git的最强大的功能之一，相比于SVN和CVS，在Git上使用分支快速和方便许多。在Git上把分支的内容合并到主干有两种方式：merge和rebase，这里以sourcetree为工具介绍一下merge和rebase的功能和区别。

假设我们现在有一个repository,这个repository有一个主干master,我在本地基于master的初始状态创建了一个分支dev，我在dev上开发一个新的功能并提交代码到dev,于此同时master上的代码也有别人在提交。现在我已经开发完了这个新功能，准备把修改的代码从dev合并到master上，假设从创建dev分支到现在master提交过一次，dev提交过一次，在sourcetree上我们看到的版本历史是这样的(蓝线是dev,红线是master)：

把代码从dev上合并到master上我们可以使用merge或者rebase。

首先来看merge，merge和SVN的merge是同样的功能，把分支的初始版本，分支的最新版本，主干的最新版本，三者进行一次三方合并计算，得到合并后的最新的版本，然后提交到主干。在sourcetree上merge的方式是现在当前working copy切换到master,然后在dev上选择merge dev into master,如图所示：

merge完成后我们看到的Git历史记录是这样的(红线是dev,蓝线是master)

使用merge，我们可以在历史记录里清楚地看到master的最后一次commit是来自dev的merge，而且"从dev合并到master"的这个信息会一直体现在历史记录里（即使以后dev这个分支被删除了）。

除了merge，我们还有另一个选择，那就是rebase。rebase的原理是把dev上的所有历史提交在master的最新版本上再逐个提交一遍。在sourcetree上rebase的操作方式如图

rebase完成后的Git历史记录如下图

我们看到如果使用rebase的话，从历史记录上完全看不出master的最后一次commit是从dev合并而来的，就好像这次合并是在master上直接修改并提交的一样。以后如果删除了dev，那么dev曾经存在过的痕迹将从历史记录里完全消失，我们从历史记录里将无法知道"曾经有一个dev分支，修改了一些代码，并合并到了master"这样一个"历史事件"。但是从另一面看，master的历史记录将变得比较清晰，不会被各种临时的分支合并记录搞得看的人头昏眼花。

转载于:https://my.oschina.net/fifadxj/blog/546651