• 安全机制, 不会每个人都拷贝一份, 可以对组员限制, 也可以分配不同组

• 团队合作开发起来传递的数据量不会过大, git因为都是镜像, 如果有个美工传个500mb的psd, 不相关的人员也要去下载, 很浪费流量和更新时间

• subversion感觉搭建非常简单支持https, 可以外部网络访问, 可以让员工在家办公, 也不用担心传递数据的流量(好邪恶)

• 每个人的电脑大小不一定能装下特别大的项目, 对于svn来讲, 公司配备一个足够大的服务器硬盘就好了, 而且哪个项目完成, 直接删掉本地目录就好, 完全没有保留的必要

• 网游公司, 广告公司这些需要大量媒体设计混合到程序的项目中, 很需要svn这样的服务器.

• svn的ui界面更加友好

但是又为什么说git更加好用呢,经过实践证明,git在开发方面确实更加随意和方便,关键就在git的分支设计上,svn上也有分支,不过据说跟没有一样,我是没用过

git优点:

• GIT是分布式的,GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。GitHub.com就是一个这样的优秀案例。这个是最重要的一点,在软件开发版本迭代中非常好用,svn在这方面无法企及.

• SVN只能有一个指定*版本库。当这个*版本库有问题时，所有工作成员都一起瘫痪直到版本库维修完毕或者新的版本库设立完成。而 Git可以有无限个版本库。或者，更正确的说法，每一个Git都是一个版本库，区别是它们是否拥有活跃目录（Git Working Tree）。如果主要版本库（例如：置於GitHub的版本库）发生了什麼事，工作成员仍然可以在自己的本地版本库（local repository）提交，等待主要版本库恢复即可。工作成员也可以提交到其他的版本库！

• 在SVN，分支是一个完整的目录。且这个目录拥有完整的实际文件。如果工作成员想要开啟新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来进行破坏工作（安检测试），那将会像传染病一样,你改一个分支，还得让其他人重新切分支重新下载，十分狗血。而 Git，每个工作成员可以任意在自己的本地版本库开啟无限个分支。举例：当我想尝试破坏自己的程序（安检测试），并且想保留这些被修改的文件供日后使用， 我可以开一个分支，做我喜欢的事。完全不需担心妨碍其他工作成员。只要我不合并及提交到主要版本库，没有一个工作成员会被影响。等到我不需要这个分支时， 我只要把它从我的本地版本库删除即可。无痛无痒。

下面是一篇oschina转过来的内容,看了之后觉得挺有用.

　　地址https://www.oschina.net/news/29214/why-git-is-better-than-svn

对SVN的迷信和对Git的误解

误解1：SVN只能检出（checkout）一个版本（revision）的代码，而Git却可以脱库！

这个误解是如此普遍，简直成了SVN在企业市场中封杀Git的尚方宝剑。其实稍微思考一下 这个谣言就很难传播。既然SVN能够读取授权访问的文件的每一个版本，那么就能够重组这些版本， 进而实现对版本库的完整复制。即SVN也可以脱库。

SVN脱库的工具SVN本身就提供： svnsync 。这个工具主要用于SVN的版本库镜像。 例如将版本库http://host.name/svn/repo 脱库到本地的 dump 目录，命令如下：

$ svnadmin create dump

$ printf '#!/bin/sh\nexit 0\n' > dump/hooks/pre-revprop-change

$ chmod a+x dump/hooks/pre-revprop-change

$ svnsync init file://$(pwd)/dump http://host.name/svn/repo

$ svnsync sync file://$(pwd)/dump

如果使用 git-svn 则为SVN“脱库”更简便。

$ git svn clone -s http://host.name/svn/repo dump

有人认为SVN可以对目录授权，从而阻止对整个版本库进行脱库操作。 下面就来看看SVN的授权究竟是否可靠。

误解2：SVN能对目录进行精细授权，而Git太不安全

SVN的目录授权对管理员来说是灾难，管理负担相当重，在分支或里程碑众多的时候很难作对。 这是因为SVN的分支和里程碑（tags）本身就是一个目录（使用目录拷贝实现的）。

例如管理员为名为demo的SVN版本库授权。一个并不太复杂的主线（/trunk）授权如下：

[demo:/trunk]

@demo-admin = rw

@leaders = r

[demo:/trunk/doc]

@demo-dev = rw

@designers = rw

[demo:/trunk/src/apps]

@demo-dev = rw

[demo:/trunk/src/common]

@demo-dev = rw

[demo:/trunk/src/html]

@designers = rw

[demo:/trunk/src/secret]

* =

@demo-admin = rw

jiangxin = rw

如果项目创建了维护分支 /branches/1.x ，若和 /trunk 授权相同，则需要将上述授权在 /branches/1.x 下重建。需要在授权文件中再添加如下授权指令：

[demo:/branches/1.x]

@demo-admin = rw

@leaders = r

[demo:/branches/1.x/doc]

@demo-dev = rw

@designers = rw

[demo:/branches/1.x/src/apps]

@demo-dev = rw

[demo:/branches/1.x/src/common]

@demo-dev = rw

[demo:/branches/1.x/src/html]

@designers = rw

[demo:/branches/1.x/src/secret]

* =

@demo-admin = rw

jiangxin = rw

如果版本库的分支和里程碑越来越多，配置的工作量相当可观，稍有不慎不是授权文件格式破坏导致SVN无法工作， 就是造成开放授权。

我曾经写过SVN路径授权的补丁，并写了一款SVN版本库管理的开源软件 （参见 《pySvnManager手册》 ）， 但想完美解决这个问题很难。我的一个设想是在SVN对分支和里程碑授权检查时缺省使用 /trunk 的授权，但这样的实现要求使用SVN严格遵循约定俗成的三个*目录的规范。

Git对于写操作可以精细到目录和分支级别（使用Gitolite作为服务器）， 但作为分布式版本库控制系统，在设计上只能实现版本库量子化的读授权。 即某用户对整个版本库要么都能读，要么对整个版本库都不能读。

那么如何控制Git版本库的读授权呢？实际上Git可以通过子模组来实现细粒度的读授权。 即在项目需要精细授权的场合，将版本库拆分为多个Git版本库进行单独授权， 再使用子模组将多个版本库整合为一个。这个操作并不复杂，而且有助于实现项目的模块化。

误解3：Git能随意改变历史提交，这对于版本控制来说是不合适的

Git对历史提交的修改只对本地提交有意义。本地提交就像是和共享版本库间的缓冲。 在未将本地提交推送到远程共享版本库之前，开发者可以后悔。可以对不完整的提交说明进行补充， 可以移除错误的提交，可以压缩合并提交等。Git对提交历史灵活的操作是Git独有的功能， 是提交审核的必备工具。

对于已经推送到远程共享服务器的提交，Git就不能再像本地一样随意更改了。 因为推送到共享版本库的提交一旦被其他程序员获取，便扩散出去， 如覆水难收，难掩众人悠悠之口。所以Git更改历史提交只对本地有效，是安全的。

相比之下，SVN本地工作区和集中式版本库之间没有缓冲，一旦发现提交了错误内容， 或写了错误的提交说明，则无法更改，除非SVN管理员介入。 SVN也允许配置为可修改历史提交说明，但是一旦管理员放开此功能， 历史提交的提交说明有可能被批量、恶意更改，并且无法恢复。

误解4：SVN对中文支持更好，Git库中的中文目录和文件名会出现乱码

我也曾经这么认为，并在《Git权威指南》第3章中用了大量篇幅介绍中文支持的注意事项。 并推荐使用Cygwin作为首选客户端，以避免GBK字符集为跨平台开发的版本库引入乱码。

一个好消息是Windows下最常用的Git客户端 msysGit 也支持Unicode了。 使用最新版本（1.7.10）的 msysGit 无需设置任何Git配置变量， 版本库中的中文文件名、目录名、提交说明都使用Unicode编码。 配合使用Unicode版的TortoiseGit（最新的1.7.9.0版本已是Unicode版）， Windows用户就不再为跨平台开发的字符集问题而伤脑筋了。

误解5：SVN的认证方式比Git丰富，比如可以实现LDAP认证

我为客户配置的Git支持HTTP、SSH协议，和Gitweb。其中HTTP协议、Gitweb都使用LDAP认证， 实现统一的口令管理。并且无论是HTTP协议、SSH协议，还是Gitweb都使用同一套Gitolite授权。

误解6：SVN更易上手，更易管理；而Git太难和太灵活了，不适合团队？

如果想把配置管理做好，无论是 SVN 还是 Git 都不容易，否则 《SVN Book》 以及我写 《Git权威指南》 也不会有那么厚了。

觉得SVN更简单的，看看下面的错误你有没有犯？

• 很多公司的SVN版本库没有遵照约定俗成的三个*目录。
• 如何配置SVN悲观锁，以便更好地对二进制文件编辑进行协同。
• 维护合并追踪的 svn:mergeinfo 属性，以便能够正确的分支合并。还要防止无此功能的客户端对其的破坏。
• SVN如何正确的反删除，直接添加删除的文件是不对的。
• 如何使用 svn:eol-style 属性，以便正确处理跨平台开发时的文件换行符问题。
• SVN管理员如何对版本库进行整理，如撤出不当提交、修改错误的提交说明。
• 版本库的安全性问题，如何做好版本库的备份。

SVN对分支当做路径来授权，造成管理的负担（参见 前面的描述 ）， 因此使用SVN实现灵活的特性分支开发、可靠的发布控制（维护分支冻结）很难。

企业应用Git的困惑之一是如何裁剪出适合自己的工作流。实际上Git本身已经给出范例：

$ git help workflows

理解Git的应用模型并选用合适的服务器端软件（如 Gitolite），可以定制出适合自己的工作流。 例如下表就是在企业中使用Git版本控制系统的典型角色划分：

		系统管理员	配置管理员	发布工程师	整合工程师	模块负责人	开发工程师
		(SYSadm)	(SCMadm)	(RELeng)	(INTegrator)	(MODmaster)	(DEV)
	创建版本库		✔
	版本库授权		✔
	版本库改名	✔	?
	删除版本库	✔	?
	创建Tag			✔
	删除Tag		✔
	创建一级分支		✔
	为分支授权		✔
	向 maint 分支强推		✔
	向 master 分支强推		✔
	向 maint 分支写入			✔
	向 master 分支写入				✔	✔
	创建个人专有分支		✔	✔	✔	✔	✔
	创建个人专有版本库		✔	✔	✔	✔	✔
	为个人专有版本库授权		✔	✔	✔	✔	✔

再来谈谈Git的使用，实际上Git的设计模型非常简单，理解了其设计思想，就可以很容易地掌握 git reset, git checkout, git rebase, git push, git pull 等命令。

误解7：程序员不喜欢命令行

谁说Git没有好的图形工具？SVN 有 TortoriseSVN，Git 同样有 TortoiseGit。 只不过Git的命令行太好用，使得图形操作显得笨拙。

至于Windows用做开发环境是否还有前途，看看火热的iOS、Android开发、和优雅的 MacBook 就知道了。

Git能做到，而SVN难以做到的事情

Git分支功能最为强大，分支管理能力让SVN望尘莫及

Git可以很容易地对比两个分支，知道一个分支中哪些提交尚未合并到另一分支，反之亦然。

• 查看当前分支比other分支多了哪些提交：

    $ git log other..
  

• 查看other分支比当前分支多了哪些提交：

    $ git log ..other
  

我不认为SVN的分支是真正的分支，因为分支最基本的提交隔离SVN就没能实现。 在SVN中一次提交可以同时更改主线（/trunk）和分支中的内容， 所以判断一个分支中哪些提交未合并到另外的分支，完全不能对SVN抱有希望。

Git可以实现更好的发布控制

针对同一个项目，Git可以设置不同层级的版本库（多版本库）， 或者通过不同的分支（多分支）实现对发布的控制。

• 设置只有发布管理员才有权限推送的版本库或者分支，用于稳定发布版本的维护。
• 设置只有项目经理、模块管理员才有权推送的版本库或者分支，用用于整合测试。

隔离开发，提交审核

如何对团队中的新成员的开发进行审核呢？在Git服务器上可以实现用户自建分支和自建版本库的功能， 这样团队中的新成员既能将本地提交推送到服务器以对工作进行备份， 又能够方便团队中的其他成员对自己的提交进行审核。

审核新成员提交时，从其个人版本库或个人分支获取（fetch）提交，从提交说明、代码规范、编译测试 等多方面对提交逐一审核。审核通过执行 git merge 命令合并到开发主线中。

对合并更好的支持，更少的冲突，更好的冲突解决

因为Git基于对内容的追踪而非对文件名追踪，所以遇到一方或双方对文件名更改时， Git能够很好进行自动合并或提供工具辅助合并。而SVN遇到同样问题时会产生树冲突， 解决起来很麻烦。

Git的基于DAG（有向非环图）的设计比SVN的线性提交提供更好的合并追踪， 避免不必要的冲突，提高工作效率。这是开发者选择Git、抛弃SVN的重要理由。

保证已修复Bug不再重现

以为创建完毕里程碑标签（tag）便完成软件版本的发布是有风险的， 往往会由于之前的版本（维护版本）中的一些 Hotfix 提交没有合并到最新版本而造成已修复问题在新版本中重现。

Git分支和合并追踪可以解决这个问题。例如用 maint 分支跟踪最新的发行版， 当确定里程碑tag v1.6.4 为最新发行版时，在 maint 分支执行如下命令以切换到最新发行版：

$ git checkout maint

$ git merge --ff-only v1.6.4

如果合并成功，代表发行版 v1.6.4 包含了所有前一个发行版的提交。 反之说明前一个发行版某个或某些Hotfix提交尚未合并到最新发行版中。

版本库的安全性

SVN版本库安全性很差，是管理员头痛的问题。

• SVN版本库服务器端历史数据被篡改，或者硬盘故障导致历史数据被篡改时， 客户端很难发现。管理员的备份也会被污染。
• SVN作为集中式版本控制系统，存在单点故障的风险。备份版本库的任务非常繁重。

Git在这方面完胜SVN。首先Git是分布式版本控制系统，每个用户都相当于一份备份， 管理员无需为数据备份而担心。再有Git中包括提交、文件内容等都通过SHA1哈希保证数据的完整性， 任何恶意篡改历史数据都会被及时发现从而被挫败。

更多的十条喜欢Git的理由

更多的十条喜欢Git的理由，参见 《Git权威指南》 第11-21页。

• 异地协同工作。
• 现场版本控制。
• 重写提交说明。
• 无尽的后悔药。
• 更好用的提交列表。
• 更好的差异比较。
• 工作进度保存。
• 作为SVN前端实现移动办公。
• 无处不在的分页器。
• 快。

什么情况推荐使用SVN

SVN具有的悲观锁的功能，能够实现一个用户在编辑时对文件进行锁定，阻止多人同时编辑 一个文件。这一悲观锁的功能是 Git 所不具备的。对于以二进制文件 （Word文档、PPT演示稿） 为主的版本库，为避免多人同时编辑造成合并上的困难， 建议使用SVN做版本控制。

原文出处：worldhello