[每日观点]20150420-软件工程-git和svn的优劣和选择

前些日子跟别人争论了一下关于git和svn该用哪个的问题，有些观点没有说透，就一直想写一篇文章写透一点，今天终于不想继续拖下去了。下面就阐述一下我的观点，顺便会提到网上有哪些错误的思维。

作为基础，第一点要提到的是，不管是git还是svn（还是其它正常的工具），它只是一个支撑工具，帮助你使用某种特定的方法完成工作，首先你自己得有方法，然后靠工具完成，而不是一种仙丹灵药，一旦服用就自动具有了某某加持。身边看到最多的情况反而是，拿着一把瑞士军刀当石头用，还以为自己已经迈入了高大上的行列。在此基础之上，git和svn在使用方法上也形成了若干经过无数人使用和优化过的优秀实践，如果不按照这些方法去使用，能够得到好结果的可能不是没有，但是也微乎其微。

第二点，正确的顺序是先选择一种方法然后选择合适的工具。如果没有这个过程（这个过程对于合格的程序员或者团队也许只是一瞬间的事情，比如前述群体中大多数选择git是因为他们选择了git支撑下的那套方法）那这就真是一个愚蠢的事情了（不管是选择了git还是svn，而且并不会因为选择了git就会蠢得略为差一点），甚至经常看到扛着红旗反红旗的事情发生。

作为一个通行的原则，我并不反对在任何情况下首选使用git，毕竟别人的团队用烂了跟我没有任何关系，而广泛使用即使是不正确地使用，对git的推广也是颇有帮助的。嗯，没错，就是死道友不死贫道的务实精神，既然要不知死活使用git，求仁得仁又何怨。

然后作为背景交代，我个人在开源社区使用git，自己使用git，工作中的团队也使用git。专门交代一句是为了避免不明真相的围观群众一时没注意喷错了人，哈哈。

终于到了正文部分了，对于问我团队开发选择git还是svn的情况，我的回答都是用svn。原因主要是但凡找我问这事的，都是平均水平到不了及格线的团队（我自己大概就是个刚刚过合格线的程序员），这种团队使用的工具以不容易出错的简单工具为佳，svn不管在概念上、操作上还是模型上都比git简单很多，对于在可以预见的将来没有什么希望把水平提升到及格线之上的团队，其实没有必要打造一块超长的木板，有这时间不如用来在其它方面做一点提升。

在这些团队里，依然有坚持要用git的，原因无非是这么几个：

1. git迷信，这种是比较常见的，其中还包括大批无法流畅操作git的人。言必称git的拥趸们，大部分情况下只是喜欢站队而已，完全不需要从事实出发，好像站对了队伍就能提升自己的境界一样。其实在时政界早有结论，左愤和右愤其实是同一类人，喜欢在技术上站队的不管站在哪队，其实也都是一类人。所以选择git还是svn其实无所谓。

2. 分布式仓库可以保证代码仓库不会丢失。这确实是个优点，不过对于你的团队，上次代码仓库在底层存储方面的原因导致代码丢失是什么时候？这种事情对于绝大多数团队是从来没有发生过的，因为绝大多数团队的代码生命周期长度短于硬件设备的无故障工作时间。代码仓库更容易出现的问题是因为误操作在逻辑上被搞乱，比如误删除误修改合并导致代码丢失等等，虽然这些错误都是可以恢复的，但是一是经常不能被及时发现二是恢复时间往往因为能力问题而花费过长的时间。在这种现状下，svn是胜出的。

3. 分布式仓库可以随时查看提交历史。问自己两个问题，一、你的团队有几个人下班之后在没有网络的地方继续工作？二、你的团队有几个人的提交频率超过每天一次？问完这个问题你可能会觉得，除了方便合并冲突之外没有SCM都不是太大的问题。

4. 速度快。我在前一家公司的时候，我见过svn的rev是6位数的代码仓库，除了checkout速度比较慢（git更慢）之外，其它操作都在几秒内就能完成。对于全生命周期总提交次数不会超过10,000次的代码仓库来说，这想法就像你为了管理你的团队通讯录而使用oracle一样搞笑。

5. 支持分布式工作。分布式确实是git的优点，它让异地团队工作简化了很多，不过前提是不同团队之间的工作不会相互阻塞，如果B团队的最新代码提交之前A团队无法继续工作，那你就享受不到git的好处。

综上，对于具备以下特征的团队，我还是建议首选svn并使用one branch的开发模型：

1. 团队技术能力差或者技术栈陈旧的；

2. 价值观上能交付产品给客户就行，质量上不追求极致的；

3. 没有分布式协同开发需求的；

4. 敝帚自珍思想比较严重，生怕那点破代码被别人偷了去的。

这并非是反话，大多数团队就是这个样子并且毫无改变的希望，认清现实并作出正确选择才能有效减少麻烦，这正是软件工程的研究领域。