首先我表明一个根本的立场，我个人更喜欢用git，但是，这仅仅是一个个人偏好。当我们需要将一种技术方案带给整个团队的时候，并不是由我们的个人偏好作为主要决定因素，而应该充分去权衡利弊，选择对团队，对公司更有效率的方案。抛开个人立场，理性评估利弊，可能才是我认可的一个资深程序员，或者一个架构师的本分。

   我所在的团队，现在选用的技术方案是git作为全公司的版本控制系统，我们一共有差不多20个程序员，使用五种以上的程序设计语言，研发维护四个左右的项目，属于小型创业公司中，研发规模中等偏上的企业。使用git作为版本控制系统，在我加入公司之前，已经是既成事实了，在我听说这一点的时候，我非常高兴，因为我说过，我喜欢git。

   上周五，我们公司新来的工程师，在周会上分享git，有个同事挑战道，为什么git比svn更好？这个问题，如果是问我个人的话，我可能会有很多的理由，但是，就像我一贯的思维模式，说服别人的时候，必须给出足够令人信服的原因，不能使用主观因素去说服别人，那样只能引起争论。

   对于，“为什么git比svn更好”这个问题，我真的很想给出一个肯定的答案，但是，我在探寻答案的过程中，遇到了困难。于是，我来尝试一下站在反面的立场来给出一份答卷，然后，我们再反过来辩论，于是就有了本文的题目。

SVN到底有什么优点

   广泛的群众基础。从我开始使用版本控制系统，我用的就已经是SVN了，所以，想要追溯SVN到底从什么时候开始，不得不求助于维基百科，我发现，SVN首个正式版本，可以追溯到2000年，距今已经十五年历史了。在github成为大热门之前，SVN基本处于一统天下的地位。几乎所有的公司都在使用SVN作为内部的版本控制系统，Google Code更是掀起了开源软件的浪潮，一时间，几乎全世界的程序员，都在使用SVN。

   我敢说，我们公司目前招聘的程序员，还没有没用过SVN的。这意味着，如果公司使用SVN的话，他们快速上手的概率，是非常高的。现在中国中小企业和创业企业，程序员招聘的困难程度，我不想多阐述——谁负责，谁头疼——如果使用SVN的话，学习版本控制系统用法这种事情，不会成为你脑海里的一个问题。

   优异的跨平台支持 。年龄大这种事情，并非总是缺点，在跨平台支持这个角度，就会成为优势。十五年来，SVN几乎积累了所有平台上优秀的客户端软件。Windows平台的TortoiseSVN的成功，简直无需赘述，甚至有程序员认为，TortoiseSVN就是SVN本身，一提到小乌龟，每个码农都会心一笑。而且，SVN本身的命令行客户端，就已经非常简洁好用了。跨平台简直毫无任何可以挑剔的地方。

   简单易用。我个人认为，SVN的易用性是无与伦比的。我刚入职腾讯的第一年，身边的程序员，是把SVN当成云端文件夹用的。整个部门，只有一个版本库，一个项目文件夹，所有的项目代码仍在trunk里面，需要开新项目，就在trunk里加一个文件夹。就算SVN被误用到这种程度，它依然没有给整个研发过程带来任何大的麻烦，一切都井井有条。你要学会的，就是在小乌龟里点点鼠标而已。

   后来，部门逐步扩大，文档增多，为了保护文档不丢失，部门运维自己架设了一个SVN服务器，让所有非程序员成员，都用SVN管理文档，各种需求，设计稿，统统用SVN管理，这个切换过程几乎没花什么时间，就是简单地给一些非技术同事培训了一下，一切都平滑异常。让五、六十号不懂技术的人，一下子用上SVN，足见其简单了吧。

   功能完善稳定。从过去七年(此时是2015年)的开发经历来看，我还没遇到过什么SVN不能处理的研发管理模型。特指在中国，公司制的研发团队管理场景下。SVN本身建议的研发流程模型，已经足足够够了，trunk用于代码主干，branches用于特性开发，tag用于发布快照，一切都流畅自然。

   我所在的团队，经过几年的摸索和磨合，已经形成了非常流畅顺滑的研发流程。有新任务来了，开分支，天天早上第一件事，同步主干变更(sync trunk)，任务完成后，分支测试，测试完毕后回归主干(reintegration)，完毕后集成测试，测试通过后，打tag，然后用内部自研上线系统，tag全量代码发布，最后分支负责人删除掉用过的分支。尤其配合SVN 1.5以后出现的merge tracking功能特性，连冲突都是很偶然的事件了。

   SVN经过15年左右的研发，功能异常完善，而且非常稳定，你熟知的命令和参数，就几乎一直保持着你熟知的那个状态，没有附加学习成本，最难能可贵的是，SVN一直在持续更新，改善效率。

git 相对SVN来说，有什么缺点？

   高昂的学习成本。不要睁着眼睛跟我说，git学习很简单啊，“学习很简单”这一个主观感受，也即，你觉得简单，只能代表你一个人的感受，如果整个团队只有你一个人，或者你们团队奉行一种精英文化，不是精英不招聘的话，你们所有人，可能都觉得学习git很简单。但是如果是一家刚刚创业的小公司，或者经营数年的中小企业，考虑其本身能从市场上获取到的人才的程度，你不得不考虑他们的接受能力。固然，公司可以花力气去培训，可是培训的时间和代价，本身就构成了“学习成本”。

   拙劣的跨平台支持。对于Windows，尤其不友好。但是请注意，Windows仍然是世界上使用最广泛的操作系统，我相信，大多数基层程序员也仍然在Windows环境下工作，那么git那近乎故意的Windows不友好，不知道到底是为了什么。无论GitHub做了什么，各种IDE做了什么，在Windows下使用git，其体验仍然是非常间接，而且不方便的。

   糟糕的抽象，复杂的结构。要想用好git，用户必须理解几个很特殊的东西，一个是分布式的结构，另一个是git存储版本的原理。这对于没空去理解他的人们来说，很不友好，你几乎不能凭着直觉去使用git，那样几乎都会把事情搞得一团糟。另外，公司里非技术的同事，几乎没法使用git工作，比如我们公司的设计师，试图使用git来管理设计稿，并进行协作，实际体验是很糟糕的，他们连新建版本库都不会。还不用提git其实对二进制文件并不怎么友好。

   你可以把事情搞得很糟糕。git整个系统，给用户提供了极大的自由度，很多操作，我们知道是危险的，但是系统并没有阻止你操作。比如，你可以把任意分支push到任意分支，比如你可以随意删除本地提交历史里的commit，比如你可以把多人共享的分支给rebase掉，你可以干出很多匪夷所思的坏事托乱全团队的速度，你可以惹麻烦，git本身没有提供任何保护机制。

一个不是结论的结论

   我完全站在SVN的拥泵角度，来阐述上面那些，我会得出这样的结论，SVN在某些场合，真的比git更合适，而我觉得，这个结论，也相对是公允的。如果公司研发成本低，研发团队小，研发人员经验参差，完全应该考虑直接使用SVN，这可能为你们团队后续发展，节省大量的时间。

   当然，还有一个要考虑的因素是研发内容的特点和研发流程的特点，是否高频次协作？是否跨公司，跨地域协作？是否海量研发人员参与的开源系统？而就我的经验看，很少有公司的研发团队能跟这些东西搭边，于是SVN理所当然成为更理智的选择。

建议继续学习：

1. Git常用命令备忘    (阅读：53145)
2. Git log diff config高级进阶    (阅读：23692)
3. Git subtree 要不要使用 –squash 参数    (阅读：22232)
4. 我的git笔记    (阅读：18753)
5. Zend Studio集成Git使用    (阅读：7976)
6. Git commit 注释格式    (阅读：5671)
7. GIT和SVN之间的五个基本区别    (阅读：4868)
8. 为何改用Git    (阅读：3900)
9. Git安装使用手记    (阅读：3859)
10. 用git部署php站点    (阅读：3482)