从git merge 和 git rebase想到……

nics

起因
　　前两天和项目组的成员分享了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来检验你的团队是否频繁提交吧。

  疑惑
　　其实，我一直难以回答的团队内部的一些问题：
　　我这么做能得到什么好处？
　　我不这么做也能达到效果呀～～
　　（于是，我就得绞尽脑汁的回答git rebase vs git merge这种问题，有时候也很享受这种过程，想想以后如果出去做咨询，面对的是客户更加严厉的质疑，回答这种问题肯定是家常便饭了，幸运的是，我真的想出一种场景，使用git rebase生成出来的一条线能更加方便的确定每次提交后的程序状态。）
　　在这里，我不想再继续纠结这些问题，我能否问你一些问题：
　　为什么你要加入Thoughtworks？
　　为什么你要写干净的代码？
　　为什么你不能频繁提交？
　　为什么你不能追求卓越？
　　
　　如果下次还有人问我类似的问题，我想我已经有答案了，那就是我们要追求卓越。