首先我表明一个根本的立场，我个人更喜欢用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理所当然成为更理智的选择。