从git merge 和 git rebase想到……

起因

前两天和项目组的成员分享了git相关知识，因为我发现大家再运行git pull时没有加后面的参数 –rebase。

也就是说，如果你运行git pull，那么git会帮你做两件事情，首先拿到远程最新的代码，然后运行 git merge。

那么如果是git pull –rebase呢？也是会拿到最新代码，然后运行git rebase。

接下来的问题就是git merge 和git rebase的区别了。简单来说，git merge和git rebase从最终效果来看没有任何区别，都是将不同分支的代码融合在一起，但是生成的代码树就稍微有些不同。（具体请猛击这里）

那么假设下面两个代码树，你愿意维护或者继续再那一个上面进行工作呢？

（1）git merge （2） git rebase

如果是我，我会选择第二个，因为它整体是一个线性开发过程，看起来一目了然。而第一种显然被很多分支搞的很乱（你能告诉我图1中那个颜色的分支是master分支么？）

分析

好吧，大家显然没有被上面的理由说服，我们又开始了很多对话。大体的意思是使用git merge有以下两个好处

1. 和git rebase的结果没有区别 -_-

2. 小组内每天下午都要code review，大家发现在review的时候，大家的提交不是按时间先后排序的，也就是说提交顺序可能如下A的22号提交，A的21号提交，B的22提交，B的21提交。用git merge就不会出现，你一定会问这和git merge有什么关系？

   答案是有关系的，看个例子把。

   我有两个相同的branch，一个是master，一个是test。我现在test上面提交 1： first commit on test，然后切换到master上面提交2： first commit on master，然后再切换到test上面，进行提交3：second commit on test。接下来，我们就要进行合并了。

   生成代码树如下图：

   如果你使用git merge，合并的结果master分支的log就是：
   复制代码

commit e0db7b4335aa5a18a5d0777578b3b313b038cd7e
Merge: e737698 6ca7468
Author: Mao Chao chaomao@thoughtworks.com
Date: Tue Dec 6 21:22:00 2011 +0800

Merge branch ‘test’

commit 6ca7468ab141dff03ec11fa4775ac7b968b18c7d
Author: Mao Chao chaomao@thoughtworks.com
Date: Tue Dec 6 21:17:37 2011 +0800

3 : second commit on test

commit e737698564c61f1472b4cb62974cf66670e2991b
Author: Mao Chao chaomao@thoughtworks.com
Date: Tue Dec 6 21:16:51 2011 +0800

2: first commit on master

commit 59820371d4df099310423736ca3fc5e9d9e30f95
Author: Mao Chao chaomao@thoughtworks.com
Date: Tue Dec 6 21:16:28 2011 +0800

1 : first commit on test branch

复制代码

可以看到log的顺序是我们想要的，是按照提交时间来排序的，因为git merge会将两个分支的合并结果放在最后。

但是如果你使用git rebase，那么你会得到：
复制代码

commit 828e9edde44ed2a830913a3bfa4008cfc3679faa
Author: Mao Chao chaomao@thoughtworks.com
Date: Tue Dec 6 21:17:37 2011 +0800

3 : second commit on test

commit 0567e43b42278839ae10231b66a6ff43e70255f9
Author: Mao Chao chaomao@thoughtworks.com
Date: Tue Dec 6 21:16:28 2011 +0800

1 : first commit on test branch

commit e737698564c61f1472b4cb62974cf66670e2991b
Author: Mao Chao chaomao@thoughtworks.com
Date: Tue Dec 6 21:16:51 2011 +0800

2: first commit on master

复制代码

表面来看，git rebase没有按时间排列全部提交，因为rebase会把当前分支的提交放在要合并分支的后面，所以test分支上面的1和3提交排在master的2提交的后面。这样显得很乱，相反git merge却给你一个按时间排列的代码树。你也许想说：我想要全部的提交都按照时间来排序而使用git merge。

这是一个大大的借口！！！

我们需要的是频繁合并！！！

git rebase忠实的保留你合并的顺序，假如你没有频繁提交、合并分支，那么你的log就会忠实的反应出来，而不是像git merge一样掩盖问题。问问自己，如果我能做到完成test分支的1提交时就合并到master上面，那么2->1->3的情况还会出现么？

所以，请勇敢地用git rebase来检验你的团队是否频繁提交吧。