HN 热帖｜难以想象，20 年前代码版本管理是如何做的

本文源自 Hacker News 热帖，原文 Twenty Years Is Nothing，作者 Adrian Kosmaczewski。

在之前的文章中，我们曾称英语在我们的行业中如此普遍，以至于没有人质疑其使用。同样，Git 也是如此。很难想象仅仅二十年前，代码版本控制工具的格局更加多元化，选择其中一种工具比今天要复杂得多。事实上，当时 Git 还没有出现在雷达上。讨论 Git 的霸权是好是坏前，我们先回到过去稍作停留。

卡洛斯·加德尔在其著名的探戈中唱道：

To feel… that life is a breath of fresh air, that twenty years is nothing, that, feverish, the gaze wandering in the shadows seeks and names you.

二十年前

2004 年 Steve McConnell 的「代码大全」第二版出版了。在这本厚达 900 页巨著的第 668 页，我们找到了整本书中唯一关于代码版本控制主题的内容：大约四分之三页长。没有别的内容了。ChatGPT 可以轻松地用一个短句总结所有内容：版本控制软件很好，并带来了几个重要好处。没有太多值得一提的东西，此时，我们距离 GitOps 还相去甚远。

同年，也就是 20 年前，Subversion 1.0 问世，和「Code Complete」几乎同时发布。Subversion 是什么？可能是计算历史上最短命的好主意之一。Subversion（或 svn）本应比 CVS 更好 [不是美国著名连锁药房 CVS Pharmacy]，是 Concurrent Versions System，版本控制系统。比 CVS 更好在当时是指具有事务性（数据库有人懂吗？）并对分支支持更好些。那时候我们还没有很高的追求，孩子们。 然而 Linus Torvalds [小编注：Linux 内核的创始人和首席开发者] 却有更高追求。2004 年，Linux 内核开发者们因 BitKeeper 产生越来越大的争议 - BitKeeper 是专有的、分布式版本控制系统，用于管理内核源代码。那么，开发者该怎么办呢？Linus 编写了每个人都需要但没人愿意开始写的软件；他还喜欢以自己的名字来命名事物。据说 Git 首个版本在数周内就写好了。

CVS

从未听说过 CVS？Joel Spolsky 于 2000 年 9 月在其同名测试「Joel 的测试」中的第一项，认为 CVS 很优秀。

我曾使用商业源代码控制软件，也用过免费的 CVS，我认为 CVS 很好。

是的，打造更优秀软件的第一步是使用代码版本控制软件。（顺便说一句，我 1997 年开启职业生涯时是一名软件开发人员，并且没有使用过代码版本控制，甚至不用 CVS。没错，你猜对了：我们只是将 VBScript 文件保存在本地然后通过 FTP 上传。如果我们互相覆盖了更改就太糟糕了：人生苦短。直到 2002 年我才第一次使用代码版本控制系统，那个系统是 Rational ClearCase [小编注：IBM 旗下的产品，简称 CC，CC 对于国内互联网软件的影响深远，比如蚂蚁集团/支付宝一开始就是采用 CC。后来虽然迁移到了 GitLab，再到内部自研的系统 LinkE，但像 CC 里的迭代概念，一直就保留了下来，也随着人员的流动，传播到了其他公司]。

从未听说过 Joel Spolsky？他是 Stack Overflow 的联合创始人，在你的职业生涯中某个时候可能用过这个网站。24 年前，Joel 是新兴领域软件工程中最早的影响者之一。想象更具争议性的 Kelsey Hightower [小编注：Kubernetes 领域最有影响力的布道师]，或者观点不那么有争议的 Steve Yegge [小编注：曾经就职于 Amazon, Google, Grab，目前在代码智能平台公司 Sourcegraph，以公开锐评公司而著称]。

说起 Stack Overflow，这里有一个 2008 年最先进的版本控制技术例子。该网站上的一个早期问题，于 2008.9.8 提出，问到在单个开发者工作流程应该使用什么版本控制系统。（有趣的是，在现实世界中，同样时间内爆发了 2008 金融危机。毫无疑问我们行业存在泡沫现象。但我又跑题了）。

我正在尝试寻找一个对我个人来说尽可能简单的代码版本控制工具。我需要的主要功能是能够阅读/拉取以前版本的代码。我是唯一的开发者。 问题的回复包含了一个长长的目录，几乎列出了当时人类所知道的每个版本控制系统。

Odyssey: Windows 版本管理工具

但让我们回到 2000 年：在 Joel Spolsky 发布他的「Joel 的测试」之前几天，Mark Lucovsky 在西雅图举行的第四届 USENIX Windows 系统研讨会上发表了一场名为「Windows: A Software-Engineering Odyssey，软件工程之旅」的演讲。Lucovsky 先生是从 1988 年到 2000 年代中期原始 Windows NT 团队的成员。这次演讲的 PPT 至今还可以在线查看，强烈建议去看看。

因为软件工程之旅的一部分是代码版本控制。在 PPT 第 14 页，你可以了解到 Windows NT 3.51 使用了一个「内部开发」的系统... 到 Windows 2000 时已经处于「勉强维持生命状态」：

保持机器同步是巨大的工作量（一周设置时间，每天二小时同步）

额。这不是吸引团队新成员的好方法。现在你知道为什么发布于 2001 年的「敏捷宣言」如此革命性了。多亏 Raymond Chen，可以说他是 Windows 历史上最重要的讲师之一，我们才知道所谓的内部开发系统的名称：

在早期，微软使用一个自研代码版本控制系统，名为 Source Library Manager，通常简称 SLM，并发音为 slime。这是一个简单的系统，不支持分支。

在 Mark Lucovsky 的 PPT 第 24 页中，我们了解到微软决定将 Windows 2000 的源代码迁移到一个名为 Source Depot 的东西。Raymond Chen 表示同意：

Windows 2000 发布后不久，Windows 源代码转移到了一个名为 Source Depot 的源代码控制系统，它是 Perforce 的授权分支。

为什么选择 Perforce？这与 Windows 庞大的源代码库有关：

原因可能不那么重要, 但 Perforce 在处理大型存储库时往往比 Subversion 表现更好。这也是微软获得 Perforce 源码许可证构建 Source Depot 的原因之一；NT 的存储库非常庞大, 并没有多少产品（无论商业还是其他）能够处理。

Mark Lucovsky 在他 PPT 第 24 页上总结了 Source Depot 两个要点:

新机器设置需要 3 小时 vs. 1 周 正常同步 5 分钟 vs. 2 小时

微软 Windows 团队是否仍在使用 Source Depot？显然不再如此。在 2017 年，我们得知微软将所有 300GB Windows 源代码迁移到 Git，在 Ars Technica 文章中描述另一篇关于 Microsoft 的历程中提到了版本控制系统:

公司曾经有过一个叫做 SourceSafe 的东西，用它等同于把你全部珍贵的源码扔进垃圾桶并点火焚毁，因为它会损坏数据库。

（我可以确认。非常遗憾。） 然而，微软采用 Git 并非没有障碍，并因此创建了 Git Virtual File System (GVFS) 项目:

但 Git 不适合处理由 350 万文件组成、共计 300GB 大小的代码仓库。微软必须着手进行项目定制化以使其能够应对公司规模需求。

Git 时代

微软对 Git 的迷恋在 2018 年达到了顶峰，当时它吞并了 GitHub，GitHub 可以说是让 Git 变得流行了起来。三年前，他们感受到了时代的气息，并发布了集成 Git 的 Visual Studio Code。

早在 2008 年 2 月，GitHub 就向世界介绍了 Pull Requests 的概念，这一功能后来被 GitLab, Gitea（及其最近的分支 Forgejo）和 BitBucket 采纳，并在过去 15 年中成为代码审核的重要工具。但事实是 GitHub 也在 Git 世界中引发了一个悖论：突然间，一个分布式源代码控制系统变得集中化。有些人对此感到不安是可以理解的。

现在是 2024，Git 无处不在。从 2010 年代开始 Git 主导的原因，可以总结为一系列开源软件的相互取代：20 世纪 70 年代的 SCCS、80 年代的 RCS、90 年代的 CVS 和 21 世纪的 Subversion。想要丝滑的迁移，SVN 可以导入 CVS 存储库，Git 可以导入 SVN 存储库。但更重要的是版本控制系统已经从类似 SCCS 和 RCS 的仅限本地系统，转移到了客户端服务器（C/S) 架构 (CVS 和 Subversion)，再到像 Git 和其他系统（尤其是 Mercurial）这样的分布式系统。

（谈到 Mercurial，火狐最近决定放弃它而改用 Git。）

这些天，我们习惯在计算机上克隆整个项目，之后可以安全地将其断开网络并继续以完全脱机的方式变成。20 年前，这种简单的范式是完全不可想象的。猜猜看：你本地仓库还包含了对项目进行的每一次更改的完整历史记录。这是一个客户端 - 服务器系统无法提供的特性（剧透警告：服务器拥有完整历史记录，而客户端只有 HEAD）。

Git（及其廉价的分支设施）对开发人员工作流程产生了持久影响。Vincent Driessen 于 2010 年 1 月发表了一篇具有里程碑意义的文章「A successful Git branching model，一个成功的 Git 分支模型」，向世界介绍了备受争议的 git-flow 概念。为什么会有争议？因为在软件行业中大多数观点都如此。现在已经出现 GitHub flow 和 Atlassian Gitflow workflow 等许多分支工作流程。

Git 仓库变得富有事件性，在每次推送、合并或标记操作时都会触发某种工作流程。一个整个行业已经崛起，并涵盖诸如 Argo CD, GitHub Actions, GitLab CI/CD pipelines 和 Gitea Runner 等名称，提供了新高度的自动化和便利性。Git 在该领域影响力如此之强大，以至于术语 GitOps 现在指代我们行业中一个完整子集。但你最好别使用分支进行部署。

问题很简单了：Git 之后会出现什么？目前来看，挑战 Git 巨大普及可能是不可能的事情。我说可能，因为在我们行业中预测未来是不可能的事情。值得一提的有两个有趣竞争者：用 Rust 编写的 Pijul（尽管该项目十年前始于 OCaml），或由 SQLite 作者编写的 Fossil 。其二，SQLite 团队列出过原因，说明为何不使用 Git：

实事求是地说，很少有人会质疑 Git 提供的用户体验并不理想。许多底层实现都反映在用户界面中。界面如此糟糕，以至于甚至出现了一个恶搞网站，生成假的 git 指令说明书。

在等待更好的替代方案时，让我们每天阅读 man 7 giteveryday 页面，并希望 git-extras, SourceTree, TortoiseGit, Fugitive, Codeberg 和 Magit 可以来解救我们。看起来，无论我们喜欢与否，未来二十年里我们可能仍然会将源代码存储在 Git 存储库中。

Hacker News 热评 🔥

ferd

现在的年轻人不会相信的，直到 21 世纪初，大多数公司使用的代码版本控制系统（比如微软的 SourceSafe, ClearCase, Perforce）都会强制你在修改之前锁定中央仓库上的所有文件...即使你只是想本地用一个文件进行一些测试也经常如此。。。太疯狂了。所以，在一个客户现场（我当时正给他们提供咨询服务），我再也无法忍受了（自 1997 年起我一直在使用 CVS）。于是我安装了 SVN 来处理他们的项目并展示给了团队。结果被称为「不负责任的工程师」...「没有锁定就修改文件太疯狂！真正的工程团队不这样做！」 开源世界至少领先 10 年。

ozim

Git 之后会是什么？

没有。我无法想象，基于文本的软件开发目前处于最佳状态。现在唯一的事情就是 AI，它可以帮助你理清或加快构建代码。AI 模型都是基于文本的语言，所有低代码或基于图像的编程并不适合作为 AI 模型的良好基础 - 生成图像显然无法像生成文本那样方便地生成用于工作软件的块状图表。

因此，文本操作将会持续存在，我们可能会有额外工具如 AI 来更快地创建/处理文本，并且 Git 已经是保留文字更改历史记录最佳模型了，而且我们需要这个历史记录，因为我们仍然需要控制由任何语言描述的复杂系统。

那些认为阅读和写作繁琐麻烦应该消失的人不会改变这种情况。即使神经链接到处都有也不能让信息回写到大脑中去，所以我认为我们还得长时间依赖阅读。虽然图像包含更多信息量，但文字可以非常精确，并且无法仅通过图像/感觉来描述复杂系统。

vertnerd

想到在二十年后，Github 可能会消失，没有人再用 Git，这是令人警醒的。我用过很多不同的版本控制系统，从 90 年代开始就用 PVCS。Subversion, CVS, Mercurial 等等其他一些我记不起名字的！我讨厌 Git，但我的所有工作现在都存储在 Github 上。它在二十年后何去何从？

后记

既然 Git 以及 GitOps 已经成了事实标准，那么作为研发工具就也自然会去拥抱它，这其中也出现了像 GitLab, HashiCorp 这样的大几十亿美金市值的公司，相互成就。而数据库开发工具领域的 Bytebase，也同样提供了业界首屈一指的数据库 GitOps 方案，可以和诸如 GitLab, GitHub, BitBucket, Azure DevOps 这些主流代码仓库 CI 流水线无缝集成。

---

💡 更多资讯，请关注 Bytebase 公号：Bytebase