首先我表明一个根本的立场，我个人更喜欢用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来说，有什么缺点？