Nate
  • 125

90%人都不知道:SVN 和 Git 的一些误解和真相

网上有很多关于 SVN 和 Git 的比较,但是大多数都是错误的,误解的。

下面给大家列出来一些常见的误解和真相,虽然这并不能说明哪个系统更好,但是可以帮助你更好的理解两个系统之间的差异

1.同样的内容,Git 仓库远比 SVN 的小

错误:他们的存储机制实际上是一样的,所以相差非常小。例外的是二进制文件,SVN 反而会远比 Git 占用的小,因为 SVN 对二进制文件也能进行差异存储。

2.SVN 创建分支代价非常昂贵。

错误:很多人认为 SVN 创建分支是复制整套代码,代价很大。实际上从 1.0 版本开始,在 SVN 里创建分支的代价已经非常非常小,你可以任意创建分支来修复一个小 BUG 或者开发新的功能

3.合并分支时需要指定版本号范围

错误:这是一个过时的误解,从 1.5 开始就不需要手工指定合并的版本号范围了,更强大的是从 1.8 版本,还提供了自动合并的功能,大大方便了分支之间的代码合并。

4.SVN 需要在每个目录下都创建一个.svn 的目录

错误:从 1.7 版本开始,已经变为只在根目录存在.svn 目录了。

5.没有人再使用 SVN 了

错误:像 FreeBSD 和 LLVM 这种有名的开源项目都还在使用 SVN。实际上,有 47%的开源项目都在使用 SVN,然而使用 Git 的只有 38%。在公司层面就更多使用 SVN 的了,因为 SVN 是真正的标准企业级版本控制系统。

6.分布式的 Git 比集中式的 SVN 更优越

错误:他们是平等的。分布式只是实现版本控制的另外一种方法。集中式和分布式两种方法都有他们的正反两面,分布式或许适合某些人,但是他也带来了某些问题,比如:没有权限控制;每个人都需要完全 clone 整个仓库,没法像 SVN 可以只 checkout 需要的子目录;没法锁定文件等等问题

7.Git 很适合大项目,SVN 不行

错误:在 Git 里每个人都需要把整个仓库都 clone 下来,2G 的仓库或许没什么问题,但是到达几百 G 后呢?你需要 clone 几百 G 的内容,想想多可怕。有个经典的解决方式就是把 Git 仓库分为多个小的仓库,但是这就导致了其他几个问题:你需要管理多个仓库;破坏了原有项目的完整性;没法继续跟他们一起使用分支;

8.Git 适合大团队

错误:某些工作流适合使用 Git,但是某些情况适合使用 SVN

9.在 SVN 里,合并总是个痛苦的事

错误:SVN 已经能很好的处理合并和冲突,已经成为他很重要的一个功能特性。只有在分支里重命名了文件夹或者文件时会有这种情况,这是个历史遗留问题。

10.Git 有灵活强大的命令行操作

正确:Git 的设计初衷就是一套低级版本控制系统,允许高级用户通过命令玩一些黑科技,但是这并不安全,对初学者也不友好。Git 也因为没有良好的设计和混乱的命令受到了一些指责:这导致加长了学习曲线和大大增加了公司和团队的成本,特别是大型团队以及团队成员水平不一的情况。比如美术、策划、开发、这类人员,技术水平线不一。

11.Git 的历史记录不安全

正确:Git 的官方描述是“笨笨的内容跟踪”,它并不关心你整个仓库历史的完整性和精确性,这导致了重命名和 git rebase 这类操作很难跟踪他们的修改记录。相反 SVN 始终都可以精确的、完整的找到你需要的变动记录。

12.Git 无法提供细颗粒的权限控制

正确:因为 Git 分布式的原因,每个人都拥有完整的仓库代码,导致每个人都有完整权限看到所有的内容。虽然这样对于开源项目来说没什么,但是对于企业来说,这是不可接受的。相反,SVN 可以设置目录级别的权限控制,你可以设置他只读或者读写,而且非常适合大型项目。

13.Git 对二进制文件存储不友好

正确:Git 因为分布式原因,无法很好的处理二进制文件,他是基于复制模式来管理的,所以并不适合有很多二进制文件的项目,比如图片多的项目。

翻译来自:svnvsgit
如有翻译错误欢迎指正
希望给那些对 SVN 有误解的朋友一个参考。
理性的认识两个不同的工具,合适的使用不同的工具,他们之间没有谁更好,只有谁更合适。

最后推荐大家一个好用的SVN仓库:SVNBucket
另外推荐大家一个SVN视频教程:https://www.bilibili.com/video/av66292191/

其他相关教程

SVN快速上手
SVN常用命令
SVN钩子解放你的双手
轻松解决SVN冲突
Mac用户SVN图形界面推荐
Eclipse安装SVN插件和检出代码
阅读 4.1k

推荐阅读
SVN系列教程
用户专栏

svn相关教程

9 人关注
7 篇文章
专栏主页