共计 3574 个字符，预计需要花费 9 分钟才能阅读完成。
师父（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…
“技术出俊杰”，还是“生态造英雄”？
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…
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 生态来帮忙团队改善研发体验、晋升研发效率。
参考资料
- 从 SVN 迁徙到极狐 GitLab
- A History of Version Control
- Version control