[笨叔点滴5] git rebase和git merge究竟有啥区别？

“ 我的数学一向不错，上次我暗恋的女生问我题目：你不是数字好吗，问你个题，1+9+0=？。这么简单的题能难得倒我，我随口一答：10。然后她哭着跑开了，还说：活该你没女朋友。”

这几天朋友圈都被长生生物这个怪物给霸占了，笨叔发的点滴都没啥人看了，上面那个段子，大家可以留言，那个女生想表达啥意思？

大家可能都知道git这个生物吧，他是由Linux祖师爷创造出来的，短短十来年时间已经霸占了代码版本管理软件的头把交椅，连不可一世的微软也在偷偷摸摸的开始偷偷使用git了，你说git的发展速度是不是和细胞繁殖一样。

大家知道git天生就喜欢分支，那么分支管理里有一个重要的方面就是分支合并了。git提供了两个分支合并的命令，一个是git merge，另外一个是git rebase，他们究竟有啥区别呢？

01 究竟有啥区别？

我们假设一个git仓库里有一个master分支，另外还有一个dev分支。如下图所示。

上述ABCDEFG这几个节点（每个节点是一个commit）都是按照时间顺序来提交的，如下表所示。

节点

提交时间

节点	提交时间
A	7月1号
B	7月2号
C	7月3号
D	7月4号
E	7月5号
F	7月6号
G	7月7号

也就是：

master分支上有：A->B->C->E 这4个节点

dev分支上有： A->B->D->F>G 这个5个节点

每个节点代表一个commit。

那么如果执行如下两个命令：

 $ git merge master

 $ git rebase master

上述两个命令都是将master分支合并到当前分支，那结果有什么不同呢？

我们先来看merge命令。

git merge master命令之后，dev分支变成如下图。

我们可以看到gitmerge master命令执行之后，dev分支上的提交都是基于时间轴来合并的。

如果我们执行git rebase master命令，会变成什么样子呢？

git rebase命令是用来改变一串提交基于那个分支为基础，如git rebase master就是把dev分支的D、F和G这三个提交基于最新的master分支上，也就是基于E这个提交之上。git rebase的一个常见用途是保持你正在开发的分支（如dev分支）相对于另外一个分支（如master分支）是最新的。

02 不如动手实验

上面说了一通，不如动手做实验。

比如我们在本地建一个git，创建如下master分支上的节点。

master分支上有ABCE这4个节点。

接下来我们创建dev分支上的ABDFG这5个节点，如下图所示。

那我们现在master分支和dev分支都建好了，下面就可以开始实验啦。我们先试试git rebase master吧。

$ git checkout dev

$ git rebase master

上述命令执行完成之后，我们来看看dev分支的情况。

执行结果是不是和我们预期的一样。dev分支和master分支是从B这个节点开始分叉的，rebase命令会让当前分支（dev分支）的节点DFG这3个节点，从master节点最后一个节点E开始生长，所以这个命令之后，dev分支最后的结果就是A->B>C->E->D->F->G

下面看一下git merge master命令。

$git checkout dev

$git merge master

最后执行的结果如下：

和我们的预取是一样一样的。merge之后的结果如下：

A->B->C->D->E->F->G->merge节点

03 总结一下吧

merge和rebase命令都是用来合并分支，那什么时候用merge命令和rebase命令呢？

Ø 当你需要合并别人的修改，可以考虑使用merge命令，如项目管理上需要合并其他开发者的分支。

Ø 当你的开发工作或者提交的补丁需要基于某个分支之上，那用rebase命令，如给Linux内核社区提交补丁。