高昂的学习成本。不要睁着眼睛跟我说，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理所当然成为更理智的选择。
Ubuntu 14.04 下搭建SVN服务器 SVN://
CentOS 6.2 SVN搭建 (YUM安装)
Windows下SVN服务器搭建和使用 + 客户端重新设置密码