代码孤岛的传说：版本控制的黎明

代码孤岛的传说：版本控制的黎明

在很久很久以前——如果我们将时间的指针拨回到二十世纪六七十年代——数字世界还是一片蛮荒之地。那时候的计算机，体积庞大到需要占据整栋建筑，运算能力却比不上今天一块智能手表上的芯片。在这片蛮荒之地中，有一个神秘的地方，它被称为「代码孤岛」。

代码孤岛上居住着一群最早的程序员，他们被称为「开发者」。那时候的开发者，与今天的我们有着天壤之别。他们使用打孔卡与机器交流，每一行代码都需要用专门的机器在纸带上打孔来表示。他们编写的程序，往往只是为了解决一个特定的问题，或者完成一个特定的任务。程序写完，任务完成，开发者便转身离去，留下代码独自在计算机的存储介质中沉睡。

这就是代码孤岛的法则：每一段代码都是一个独立的王国，开发者就是这个王国的绝对君主。代码与代码之间，老死不相往来；今天的开发者与昨天的开发者，也几乎没有任何交集。每一个新项目，都从零开始；每一次代码的修改，都是对原文件的直接覆盖。如果你想保存一个「备份」，最常见的做法就是复制整个文件夹，然后在文件夹名字后面加上日期，或者加上「_backup」，或者加上「_new」，或者加上「_final」——然后你就会发现，你的硬盘上很快就会充斥着「final」、「final_v2」、「final_final」、「final_final_v2_final」这样令人崩溃的文件名阵列。

备份的诅咒

让我们把时间定格在1980年代的某个普通工作日。约翰是一名在某大学计算机实验室工作的研究员，他正在开发一个用于气象数据处理的程序。这个程序已经花费了他三个月的心血，代码量超过了一万行。某个清晨，他开始对程序进行一项重要的优化——他打算重构数据处理的核心算法，这将大幅提升程序的执行效率。

约翰小心翼翼地打开了程序的主文件，开始修改代码。他修改了几行，保存，然后编译。编译成功了，但运行时程序崩溃了。没关系，约翰想，调试本来就是开发的一部分。他仔细检查了崩溃的原因，发现是自己新写的代码有一个逻辑错误。他修改了错误，再次编译，程序能运行了，但输出结果不正确。他又开始调试，如此往复。

三个小时后，约翰发现事情变得不对劲了。他的程序现在根本无法编译——编译器报出了一大堆莫名其妙的错误。他试图回溯自己做了哪些修改，但三个小时的频繁改动让他完全记不清了。「如果当初保存了备份就好了」，约翰懊恼地想。但问题是，他确实保存了备份——他有一个「backup」文件夹，里面有「data_v1.c」「data_v2.c」「data_v3.c」...一直到「data_v15.c」共十五个版本。然而，当他打开这些文件时，他发现了一个令人绝望的事实：他根本不知道哪个版本是好的，哪个版本是坏的，哪个版本是在哪个状态下保存的。

约翰花了整整两天时间，从这十五个版本中艰难地拼凑出了一个能工作的程序。这两天里，他无数次地幻想：如果有一个系统，能够清楚地记录下每一次修改的内容，能够让我轻松地回到任何一个历史状态，那该有多好。

约翰的故事并不是个例。在那个年代，几乎每一个开发者都经历过类似的噩梦：代码改着改着就坏了，想要回退却发现已经覆水难收；备份文件一大堆，却不知道哪个是最新哪个是最旧；多人协作时，你改一下我改一下，最后谁的代码覆盖了谁的代码都说不清楚；不小心删除了关键文件，整个项目可能就毁于一旦。

这种痛苦的根源在于：在代码孤岛时代，开发者只能依靠人工来管理代码的历史和状态。而人类的记忆是有限的、粗心的、不可靠的。我们需要一个系统，一个能够自动记录每一次修改、能够让我们在任意历史状态间自由穿梭、能够让我们安全地进行多人协作的系统。这个系统，就是版本控制系统。

RCS：黑暗中的第一缕曙光

时间来到了1985年。这一年，一位名叫Walt Tetsch的程序员发布了RCS（Revision Control System，修订控制系统）。这个看似简陋的工具，却标志着人类历史上第一次系统性地尝试解决版本控制问题。

RCS的原理简单而巧妙。它的核心思想是：将文件的每一次修订都保存为一个完整的快照，而不是只保存修改的差异。乍一看，这种做法似乎很浪费空间——如果一个文件有一千行，每次修改只改了一行，那保存十次修订就需要保存十份完整的文件。但RCS的设计者考虑到了存储空间的限制，他们引入了一种叫做「差分存储」的优化技术：当保存新版本时，RCS会计算出与上一个版本的差异，只存储差异部分。这就是后来被称为「增量存储」或「diff存储」的技术的基础。

更重要的是，RCS引入了「锁定」机制来解决多人协作的问题。当一个开发者想要修改某个文件时，他需要先「锁定」这个文件。锁定后，其他开发者只能读取这个文件，不能修改。只有当锁定者「解锁」后，其他人才有机会锁定并修改。这种机制虽然简单，却有效地防止了「两个人同时修改同一文件，导致其中一个人的修改被覆盖」的问题。

让我们通过一个简单的例子来理解RCS是如何工作的。假设你有一个名为`hello.c`的文件：

```c #include <stdio.h>

int main() { printf("Hello, World!\n"); return 0; } ```

第一次使用RCS时，你需要创建一个RCS库来存放这个文件的版本历史：

```bash

创建RCS目录并签入初始版本

$ mkdir RCS $ ci hello.c hello.c,v <-- hello.c enter description, terminated with '.' or end of file: NOTE: This is NOT the log message! >> 初始版本：Hello World程序 >> . initial revision: 1.1 done ```

`ci`命令是「check in」的缩写，意思是将文件签入版本库。现在，RCS创建了一个名为`hello.c,v`的文件（`.v`后缀表示这是RCS的版本文件），存储在`RCS`目录中。这个文件包含了文件的初始版本以及一些元数据。

当你想要编辑这个文件时，你需要先「检出」（check out）它：

```bash $ co -l hello.c hello.c,v --> hello.c revision 1.1 (locked) writable `hello.c' expires locked by: tetsch done ```

`-l`参数表示锁定检出。检出后，你可以自由地修改`hello.c`文件。修改完成后，再次使用`ci`命令签入：

```bash $ ci hello.c hello.c,v <-- hello.c new revision: 1.2; previous revision: 1.1 enter log message, terminated with '.' or end of file: >> 添加了注释说明 >> . done ```

现在，版本从1.1升级到了1.2。RCS会自动计算出差分，只在版本文件中添加新的差异内容。

RCS还提供了查看历史的功能：

```bash $ rlog hello.c

RCS file: RCS/hello.c,v Working file: hello.c head: 1.2 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 2

description: 初始版本：Hello World程序

revision 1.2 date: 2024/01/15 10:30:00; author: tetsch; state: exp; lines: +2 -0 添加了注释说明 revision 1.1 date: 2024/01/15 09:00:00; author: tetsch; state: exp; lines: +7 -0 Initial revision ```

`rlog`命令显示了文件的完整修订历史，每一条记录都包含了版本号、日期、作者、变更的行数，以及提交时填写的日志信息。

RCS的诞生是一个重要的里程碑。它第一次将版本控制从「人工备份」的泥沼中解放出来，引入了自动化的版本历史管理。开发者终于可以追溯每一次修改的记录，可以在任意版本之间切换，可以用日志来记录每一次变更的目的。

然而，RCS也有明显的局限性。首先，RCS是基于单个文件的。每个文件都需要单独管理，你无法将一组相关的文件作为一个整体来处理。其次，RCS的锁定机制过于简单粗暴。在锁定期间，其他开发者完全无法修改该文件，这在大型项目中会造成严重的效率问题。如果一个开发者度假去了，他锁定的文件就无人能动了。

尽管如此，RCS的出现仍然具有划时代的意义。它证明了版本控制是可行的、有价值的，为后来更先进的系统奠定了基础。

CVS：协作时代的来临

时间来到了1986年。在RCS的基础上，Dick Grune开发了CVS（Concurrent Versions System，并发版本系统）。这个系统的名字中包含了「并发」（Concurrent）一词，表明它的设计目标正是解决RCS在多人协作方面的不足。

CVS的核心创新有两点。第一，它引入了「仓库」（Repository）的概念。RCS的版本文件散落在项目目录的各个角落，与源文件混杂在一起。CVS则将这些版本文件集中存储在一个统一的仓库中，与工作目录完全分离。这意味着，你可以在同一套版本库上工作，而不必担心版本文件会弄乱你的项目结构。

第二，也是更重要的，CVS放弃了RCS的锁定机制，转而采用「合并」（Merge）策略。当两个开发者同时修改了同一个文件时，CVS会尝试将他们的修改自动合并；如果无法自动合并（比如两个人修改了同一行代码），则将冲突标记出来，交由开发者手动解决。这种策略被称为「乐观并发控制」——它假设大多数时候，开发者之间的修改不会冲突，因此允许所有人同时工作，只有在真正冲突时才需要人工介入。

让我们看看CVS的基本用法：

```bash

检出整个项目到本地

$ cvs checkout myproject cvs checkout: Updating myproject U myproject/README.txt U myproject/src/main.c U myproject/src/utils.c ...

进入项目目录

$ cd myproject

编辑文件

$ vim src/main.c ...进行修改...

提交修改

$ cvs commit -m "修复了登录模块的边界条件问题" cvs commit: Updating . Checking in src/main.c; /usr/local/cvsroot/myproject/src/main.c,v <-- src/main.c new revision: 1.5; previous revision: 1.4 done

获取他人的最新修改

$ cvs update cvs update: Updating . M src/utils.c U src/new_feature.c ... ```

`cvs update`命令会从服务器拉取其他开发者的修改，并与本地修改进行合并。如果有冲突，CVS会在冲突位置标记出来：

```c <<<<<<< 你的修改在这里 ======= 服务器上的修改在这里 >>>>>>> 1.4 ```

开发者需要手动解决这些冲突，删除标记并保留正确的代码，然后再次提交。

CVS还引入了「标签」（Tag）和「分支」（Branch）的概念。标签用于标记某个特定时刻的所有文件，比如发布版本；分支用于创建独立的开发线，允许部分功能在分支上实验而不影响主线。这两个功能在RCS中要么没有，要么非常简陋，CVS让它们变得实用起来。

CVS的出现，彻底改变了软件开发的方式。在此之前，代码协作意味着「我改完了发给你，你改完了再发给我」这种邮件传来传去的原始方式。有了CVS，所有开发者可以共享一个版本库，每个人都可以看到其他人的工作进度，修改可以自动合并，冲突可以及时发现。这标志着软件开发从「单打独斗」向「团队协作」的转变。

CVS迅速成为了开源社区的首选版本控制系统。1993年，CVS被集成到GNU工具集中，成为了自由软件的标配。整个1990年代和2000年代初，CVS几乎就是版本控制的代名词。

然而，CVS也有其固有的缺陷。首先，CVS的架构设计存在根本性的问题。它的版本库是基于RCS文件的集合，每个文件的版本历史是独立管理的。这种设计使得「原子提交」（atomic commit）变得几乎不可能——在CVS中，你提交一批文件时，每个文件是单独提交的，如果中途失败，某些文件已经更新，某些文件还没有更新，版本库就会处于不一致的状态。其次，CVS的分支功能非常笨拙。创建一个分支需要复制整个版本库（物理复制），这在大型项目中会导致存储空间的急剧膨胀和操作的极度缓慢。

这些问题在小型项目中可能不明显，但在大型项目中却会变成致命的瓶颈。随着Linux内核这样的超大型项目开始使用CVS，它的缺陷日益暴露。

黑暗中的巨人：Linus与Linux的故事

在讲述Git的诞生之前，我们不得不把目光转向一个关键人物——Linus Torvalds，以及他创建的Linux内核项目。正是这个项目，直接催生了Git的诞生。

1991年，21岁的芬兰学生Linus Torvalds开始开发一个操作系统内核。他把这个项目命名为「Linux」，这是「Linux is NOT UniX」的递归缩写（这种自我指涉的命名方式后来成为了极客文化的一部分）。最初，Linux只是Linus一个人的作品，但随着源代码在互联网上的发布，它迅速吸引了一批志愿者的加入。

到了1990年代末，Linux内核已经发展成为一个拥有数百万行代码、数千名贡献者的巨型项目。每天都有来自世界各地的开发者提交补丁、报告bug、讨论设计决策。如何管理这样一个庞大的项目，成为了一个严峻的挑战。

早期，Linux内核使用邮件列表来管理补丁。开发者编写补丁后，通过邮件发送给Linus，Linus手动审查后决定是否合并。这种方式在项目规模较小时还能运作，但随着项目增长，它很快就暴露出了严重的问题。

首先是效率问题。Linus每天会收到成百上千封邮件，每封邮件可能包含一个或多个补丁。如果所有补丁都通过邮件来传递和讨论，版本库的状态实际上是模糊的——没有人能准确地说出「当前内核的完整状态是什么」，因为版本库根本不存在，所有人都只有自己本地的代码副本。

其次是合并问题。当两个开发者同时修改了相似的内容时，他们各自的补丁可能在逻辑上冲突。在邮件模式下，这种冲突只能通过邮件反复沟通来解决，效率极低。

2002年，Linux内核项目做了一个重大的改变：他们开始使用BitKeeper作为版本控制系统。BitKeeper是一款商业软件，由BitMover公司开发，它的核心卖点正是「分布式版本控制」。

BitKeeper的分布式模型与CVS截然不同。在CVS中，只有一个中央版本库，所有开发者都必须连接到这台服务器才能获取代码、提交修改。在BitKeeper中，每个开发者都有一个完整的版本库副本，包含所有的历史记录。开发者可以完全离线工作，在本地提交、创建分支、合并修改。只有在需要与他人同步时，才通过网络推送或拉取变更。

这种模式对于Linux这样的分布式项目来说是完美的。每个开发者都可以有自己的版本库，不必依赖中央服务器；补丁可以通过版本库的推送和拉取来分发，比邮件附件更加可靠；合并操作可以在本地完成，不必担心网络延迟或服务器故障。

Linus Torvalds对BitKeeper赞不绝口。在2003年的一次演讲中，他说：「BitKeeper是目前唯一能处理Linux内核规模的版本控制系统。我不相信有任何开源替代品能做到这一点。」

BitKeeper为Linux内核项目服务了将近三年时间。然而，2005年，一个戏剧性的事件打破了这种平衡：BitMover公司宣布，Linux内核社区的免费使用许可到期了，他们将不再提供免费版本。

关于这件事的具体原因，有多种说法。一种说法是，有人逆向工程了BitKeeper的协议，违反了许可条款。另一种说法是，BitMover认为开源社区的免费使用是一种不公平的商业竞争。无论原因是什么，结果是明确的：Linux内核项目失去了他们的版本控制系统，Linus Torvalds面临一个艰难的抉择——要么付费使用BitKeeper，要么切换到其他系统。

转折点：Git的诞生

2005年4月，Linus Torvalds做出了一个决定：他将自己开发一个新的版本控制系统。这个系统必须满足几个苛刻的要求：

首先，它必须能够支撑Linux内核这样的超大型项目。Linux内核有数万个子目录、数百万行代码，每天有数千次提交。没有一个现有的开源系统能够处理这种规模。

其次，它必须支持分布式开发模式。Linus已经习惯了BitKeeper的分布式工作流程，他不想回到集中式版本控制的老路。

第三，它必须非常快。Linus是一个性能至上主义者，他无法忍受任何一个会拖慢他工作效率的工具。

第四，它必须保证数据的完整性。版本控制系统中存储的是开发者心血的结晶，任何数据的损坏或丢失都是不可接受的。

2005年4月3日，Linus Torvalvals在Kernel.org邮件列表上宣布了Git项目。他说：「我正在开发一个新的版本控制系统，它的名字叫做Git。我花了一周的时间写它的核心代码，现在它已经可以基本工作了。」

这个消息在开源社区引起了轰动。有人惊讶，有人怀疑，有人期待。毕竟，一个操作系统内核的创建者，现在要开发一个版本控制系统——这是他擅长的领域吗？

Linus用行动回答了这些疑问。在接下来的几周里，Git以惊人的速度进化着。4月6日，Git支持了diff和log命令；4月7日，支持了branch和checkout；4月9日，第一个公共仓库被创建；4月12日，Linus将Linux内核的Git仓库推送到了公共服务器上。

仅仅一个月后的5月，Git就正式承担起了Linux内核版本控制的重任。此后，Git继续快速发展，功能不断完善，性能不断优化，逐渐成为了开源社区最受欢迎的版本控制系统。

2010年，GitHub的联合创始人Tom Preston-Werner在一次演讲中说：「Git不仅仅是另一个版本控制系统。它是一种全新的工作方式，是一种让协作变得更加简单和高效的工具。」

如今，Git已经成为软件开发的事实标准。据统计，全球有超过90%的软件开发项目使用Git作为版本控制系统。从最小的个人项目到最大的企业级应用，从个人开发者到成千上万人的开发团队，Git无处不在。

设计哲学：Git背后的智慧

要理解Git为什么能够取得如