师父（80 后老员工）：小吉啊，我看我们文档越来越多了，手动管理起来很费劲。你去搞一个 SVN 来用一哈，做个版本控制，这样大家都方便。

徒弟（95 后新力量）：师父啊，S 什么，什么 VN？是干什么的？

师父：Too young too simple，Subversion 做版本控制的神器啊，老少皆宜。

徒弟：emmmm，没听过。大家都用 Git 啊，基于 Git 的 GitHub/GitLab/极狐 GitLab 用着多香。师父，你用的这些都 OUT 了吧。

师父：你走，不要再让我看到你，以后出事了，不要说我是你师父。

因为一个版本控制工具之争，让美好的师徒关系变得紧张起来。看来要说服师傅，还得深挖一下版本控制的内容啊。

为什么需要版本控制？

先来看看维基百科对于版本控制的定义：

在软件工程中，版本控制（version control）（又称之为 revision control、source control 或者 source code management）是一种典型的系统，负责对计算机程序、文档、大型网站或其他信息集合的变更进行管理。版本控制是软件配置管理的重要一部分。

简言之：版本控制是为了对软件研发过程中的所有变更（代码、文档、配置等）进行追踪管理。

版本管理是实现多人对于同一套代码进行高效协作研发的关键，可以清楚记录某个变更的详情，诸如变更人员信息（作者、邮箱）、变更内容（增加、删除）、变更原因及变更日期等。当有问题的时候，还可以进行快速回滚。

波澜壮阔的版本控制发展史

版本控制的发展史，要追溯到上世纪 60 年代，有这样几个主要的里程碑事件：

▹1962 - IEBUPDTE

IEBUPDTE 主要与 IBM's OS/360 系统一起使用，被称为版本控制工具的先驱，可追溯到 1962 年。虽然其主要使用穿孔卡来存储数据，但是确实提供了类似于今天用补丁系统创建和更新代码库的能力。

▹1972 - SCCS

1972 年，贝尔实验室开始创建 SCCS（Source Code Control System），由 Marc Rochkind 用 C 语言编写。这个系统已经初具现代版本控制系统的特点了，诸如具备创建、编辑以及追踪文件的能力。当然，这个系统并不支持多人同时协作。SCCS 在 1977 年正式对外发布，是上世纪 80 年代最主要的版本控制系统。

▹1982 - RCS

1982 年，Walter Tichy 开发了一个称之为 RCS（Revision Control System）的系统。虽然 RCS 依旧是任何时刻只允许一个用户对单个文件进行编辑，但是他创造了一种称之为 “Reverse Deltas” 的变更存储方式。RCS 并未存储当个文件的所有变更版本，而是将其最近的一个版本作为基线，其他所有版本都基于此基线来创建，这大大提高了变更存储以及追踪效率。

▹1986 - CVS

在不久之后的 1986 年，Dick Grune  也用 C 语言开发了 CVS（Concurrent Versions Systems）。CVS 允许同一时刻由多个用户对同一文件进行操作，已经和现代版本控制系统非常接近了，因为它通过 “差异” 来记录和追踪变更，同时使用了经典的 C/S 模型（Client-Server）以及分支方式。

▹2000 - SVN

2000 年，由 CollabNet 创建的 SVN（Subversion），是现如今大家耳熟能详的版本控制系统。SVN 兼具 CVS 很多功能特性，在 2010 年更名为 Apache Subversion 并捐赠给了 Apache 基金会。

SVN 是典型的集中式版本控制系统（CVCS，centralized version control system）。项目存储在服务器端，用户需要通过客户端（非常流行的客户端有 Tortoise SVN 和 SmartSVN）来进行变更的拉取和提交。

▹2005 - Git

Git 是 Linux 内核创始人  Linus Torvalds 的又一佳作，是典型的分布式版本控制系统（DCVS，Distributed Version Control System）。由于 Git 在分支操作方面的灵活性以及生态发展方面（下文将进一步说明）优良性，吸引了越来越多企业和用户。目前 Git 是版本控制的主流工具。

SVN 日薄西山，Git 一枝独秀

进入 20 世纪，SVN 和 Git 逐渐成为主流的版本控制系统。但是随着时间的推移，Git 已经超越 SVN 成为最受欢迎的版本控制系统，这一点可以从 Google 近年来的搜索趋势上得以佐证：

图片图注：蓝色代表 SVN，红色代表 Git

在 2011 年之前，SVN 的搜索量一直高于 Git，但是之后 Git 搜索量持续攀升，而 SVN 的搜索量却持续下降。

另外，在 2022 年 StackOverFlow 调研中，也体现了相同的结果：

在版本控制系统使用调研中，71379 名受访者中，93.87% 的人在使用 Git，只有 5.18% 的人在使用 SVN，Git 使用量是 SVN 的近 20 倍，足以看出 Git 的受欢迎程度。

图片来源：https://survey.stackoverflow.co/2022/#version-control-version-control-system

“技术出豪杰”，还是 “生态造英雄”？

SVN 和 Git 存在诸多方面差异，诸如：

• SVN 是集中式的，Git 是分布式的；

• SVN 的分支操作成本（创建/删除/合并）比 Git 高；

• SVN 是存储“变更差异”，Git 是存储“文件快照”。

此外还有使用体验（拉取速度、命令操作）、原理理解等方面的不同，但是技术特点的区别，绝不是造成如今现状的关键因素，真正的关键要素是生态。

这篇文章不会深入探讨 SVN 和 Git 的具体技术细节与差异，感兴趣的可自行前往SVN 官网 和 Git 官网查看文档自行对比。

SVN 和 Git 的生态截然不同，从 DevOps 与开源两个方面可见一斑。

源代码托管平台生态

围绕 Git 产生了很多源代码托管平台，有开源的，也有专有的，其中就出现了 GitHub 与 GitLab 两个世界级源代码托管平台。GitHub 前段时间公布，其开发者数量达到了惊人的 1 亿，而 GitLab 作为全球第二大代码托管平台，其用户数也高达 3000 多万。

这两大平台成为全球开发者、企业用户的集散地，大家在平台上通过协同研发，创造一个又一个创新成果。

这一点，同样在 StackOverFlow 的源代码托管平台调研报告中得到验证：

图片来自：https://survey.stackoverflow.co/2022/#version-control-version-control-system

67035 受访者表示 GitHub、GitLab 是使用率排名前二的平台，远高于 Bitbucket、 Azure Repos 以及其他类似平台。

反观 SVN，虽然也有企业提供基于 SVN 的源代码托管平台，但是远远未达到 GitHub/GitLab 同等规模，甚至鲜有人知。

因此，在基于 SVN 打造的源代码托管平台生态上，SVN 确实没有多少亮眼之处。

应用程序交付生态

如今，各企业组织都积极拥抱 DevOps ，旨在实现应用程序的高效、安全交付，进而为客户带来更大价值。而围绕 DevOps 产生了繁杂的工具链，除了上文提到的 GitHub/GitLab 源代码托管平台，还包括很多其他工具。

如 CI/CD，对于 CI/CD “网红级” 产品 Jenkins 来讲，其通过插件方式来提供各种服务，而基于 SVN 的插件只有 13 款，但是基于 Git 的插件却有 85 款之多，足足是前者的接近 7 倍：

此外，云原生交付“新贵”Tekton ，目前也仅支持 GitHub/GitLab/Bitbucket 作为 Repo Interceptor，SVN 并不在列。

同样的，实现 GitOps 的利器——ArgoCD，在仓库配置上仅支持通过 SSH 或 HTTPS 的方式链接到 GitHub/GitLab 上，SVN 同样不在列中。

这些都从侧面印证：当前应用程序的交付生态，基本围绕以 Git 为基础的相关平台，而非 SVN。

开源生态

开源成为了近年来的热门话题，涌现出众多的开源项目，全球两大顶级基金会（Linux 基金会和 Apache 基金会）托管的开源项目就多达数百个，此外还有很多个人开发者、企业、组织开源项目。

如此之多的开源项目都是托管在 GitHub/GitLab（GitLab 本身是开源的，托管在自身平台上），如前文所说，这两个平台都是以 Git 为技术底座，而不是 SVN。所以，Git 类平台和开源发展是紧密 “绑定” 的。

因此，围绕 Git 的生态发展速度很快，并且正在持续推动 IT 技术发展，而围绕 SVN 的生态却没有太多发展，或者说鲜有人知。因此，生态才是 Git 比 SVN 发展更繁荣的真实原因和背后逻辑。

是时候从 SVN 切换到 Git 了，体验 Git 生态带来的便利与快捷，同时用 Git 生态来帮助团队改善研发体验、提升研发效率。

参考资料

1. 从 SVN 迁移到极狐GitLab
   

2. A History of Version Control
   

3. Version control