关于git以及分布式SCM的一些观点

这几天对git感兴趣，看了一些web cast以及一些相关文章，形成了一些观点，却还不成文章，零零散散说一下，欢迎大家一起讨论。

第一感觉与第一感觉所造成的影响

自从有了协作开发以来，大家就开始有了管理代码的需求，说到底，软件工程里有什么比代码更重要的呢？所有的实践均围绕着最终如何形成以及形成什么样的代码。最早期如果需要两个人一起写一段代码，最终一定是需要某一个人把两个人的工作合并在一起，于是产生了自动代码管理工具的需求。CVS的出现是基于于这个需求的第一感觉解决方式————找个地方把代码放起来，大家都来这里改代码（提交自己的delta)。这样做的影响是什么呢？
  1 当参与人数越来越多的时候，人员素质开始良莠不齐，即使合格的程序员往往对项目的理解也存在这样或那样的分歧，而最终的保存代码的地方只有一个，究竟那些人有权限提交代码开始演变成一场政治游戏。
  2 当代码越来越庞大的时候，单个人对全体代码的了解越来越少，于是开始变得越来越不关心，只求自己的事情做完，而欠缺对周围的考虑。好比自家的厕所往往很干净，而公共厕所往往臭不可闻。于是代码越来越庞大，越来越像一个迷宫。

这个表还可以继续列下去，不过我只就自己想的清晰的部分展开讨论，模糊的地方还有赖大家一起完成清晰化。对于1，后续的SCM和一些软件工程实践尝试在Centralize Model上打补丁，比如局部提交权限等perforce,svn特性。更常见的，相信很多项目都有所谓的sanity check(也有叫smoke的），也就是说一次提交至少要在本地机上通过了某些基本测试，不会影响到其它模块在回溯测试中的表现，才被允许提交。在我以前工作的地方，如果提交的代码break sanity,提交人是要买donut回办公室来赔罪的。然而这样的标准极大的挫伤了大家的提交积极性，小改动小feature影响不明显，然而我曾经见过某个大feature连续两次miss大版本cut，最后找人专门fine merge了两个多月。而对于2，由于代码对团队中大部分人都是未知远多于已知，最近几年大家都寄望于某些可以提高代码质量的实践，从最早的极端重视文档，到重构，再到现在流行的code review。然而这些都是基于一个假设————项目内有一个最重要的中心代码主干。综上所述，由最初的一个第一感觉所形成的一个模式，衍生出了很多SCM软件以及软件工程实践，下面简单论证一下很多这些东西在分布式SCM内并不需要。

分布SCM为什么没有以上问题

首先这个帖子不介绍git或者mercurial，相关信息应该不难获得。大体上在一个分布式环境中并没有一个每个人都提交和签出代码的主干，然而澄清一点，这并不代表每个开发人员的每个分支都是同等重要的，大家可以看一下这个网站。在分布式的情况下并没有什么人掌握着整个项目的提交权限与发放。每个人git clone自己要的code base，自己git push自己的版本，需要的人（或许是integration manager,或许是lieutenant）git push自己所信任的分支。一个项目完全可以建立一个experiment branch，甚至个人也可以建立任何随兴而至的branch（然而在centralize model里建立分支是每个人都能看见的，相当于一个平面DAG，每个人所看见的都是这个DAG,于是这个DAG必须“有意义”）。从这个角度看,git最大的优点就是没有随意假设任何东西，比如一个共有空间来存放代码，而是提供了一系列的工具方便大家交换和共享代码，自然也可以轻易用这套工具来构建类似于cvs/svn/p4的centralize model。

分布式SCM对软件工程的影响

较为常见的思潮是分布式更适合松散的开源编程。我不同意这样的看法，我认为分布式和松散组织没有逻辑上的必然联系。分布式SCM最大的优点就是把具体的人和代码紧密地联系在了一起。我想我们大家都厌倦了所谓的PPT架构师。kernel.org至今没有谁号称是架构师，Linus本人甚至贡献了超过2%的代码。我认为git很容易形成这样一种风气：无论是你自己写的，还是你pull别人的代码，你最终要对自己repo里的代码负责。我相信在git的环境中，大家不需要组织定期的重构，因为别人如果看不懂你的代码结构是不会pull你的repo的，同样的原因，也不需要强制性的code review。你如果无法举证你的改动是有效的，同样不会被pull（这样写单元测试至少是直接的压力）。无论是lieutenant还是dictator本人都需要非常的在意自己的代码质量，因为在git环境中pull与不pull是对质量的一个评价，这是Centralized SCM所欠缺的（会有一些侧面的指标尝试量化，从而吸引大家追求，进而产生number hack practices,偏离初衷）

话有些乱，主要目的是抛砖引玉，引起大家对distributed SCM的兴趣，进而一起讨论。

ms上面的连接是：http://whygitisbetterthanx.com/#any-workflow

订正了,谢谢

我仔细研究了一小下GIT，感觉分布式还是无法解决“合并”的繁琐。所以单纯看Configuration Repository的话，Git这种分布式确实存在优势，但结合诸多的平台、插件，应该说还没到那种“完胜”的程度吧~

如果说还有什么没有完胜的，大概就是使用习惯吧，毕竟这个世界上还存在认为VSS有价值的人。

关于merging的复杂性，第一以pull为主要获取手段的git/mercurial等已经可以做到总有合适的人做合适的工作了，第二技术上毕竟还有诸如cherry picking等等手段。即使你仍然觉得繁琐，相比svn等已经是不可同日而语了。

linus本人曾经嘲笑svn着重介绍branching有多快多快，然而merging才是衡量效率的关键，可见分布scm这点已经走在前面了。