Name: Git修炼之道
Author: MiniMax-M2.7-highspeed

版本控制的起源与演进

第1章：版本控制的起源与演进

软件开发的本质是一个不断迭代、持续演进的过程。在这个过程中，代码文件被反复修改、扩展、优化，有时甚至需要回退到之前的某个状态。想象一下这样的场景：你正在开发一个重要的功能，经过数小时的努力，代码结构已经面目全非，突然发现之前的一个方案更加合理，但你已经覆盖了那些文件；或者你和团队成员同时修改了同一个文件，合并时发现两个人都对同一行代码做了不同的改动，你只能凭记忆判断哪个版本是正确的。这些问题在软件开发中极为常见，却长期困扰着开发者们。直到版本控制系统（Version Control System，VCS）出现之后，这些困境才得到了根本性的解决。

版本控制是一种记录文件变化历史的系统机制，它能够追踪文件的每一次修改，保存不同时间点的快照，并在需要时将文件恢复到之前的任意状态。更重要的是，版本控制系统允许多人协作，每个人的工作可以在同一套版本管理体系下有序进行，既能追踪每个人的贡献，又能有效处理多人同时修改带来的冲突。可以说，没有版本控制，现代软件开发的规模化和协作化就无从谈起。

手动文件备份时代

在计算机发展的早期阶段，版本控制的概念尚未形成，开发者们只能依靠最原始的方式来保存代码的历史版本。这种方式说起来再简单不过：当你想保留当前代码状态的时候，就把整个目录复制一份，给它起一个带有时间戳或版本号的名字，然后存放在某个地方。这种做法被称为手动备份法（Manual Backup），或者按照Unix文化的传统，被称为“sccs”（Source Code Copy and Store，即复制并存储源代码）。

让我们用一个具体的例子来理解这种工作方式。假设你正在开发一个计算器程序，项目的源代码目录叫作`calculator`。在开发初期，这个目录可能只包含几个简单的文件：

``` calculator/ ├── calculator.c # 主程序文件 ├── parser.c # 表达式解析器 ├── evaluator.c # 表达式求值器 └── Makefile # 构建配置文件 ```

当你完成了第一阶段的基本功能开发后，你可能会备份整个目录：

```bash $ cp -r calculator/ calculator_v1.0/ ```

经过一周的开发，你又添加了科学计算功能、改进了解析器、修复了若干bug，此时原始目录`calculator/`已经发生了翻天覆地的变化。如果你想保留这个新版本，你会再次备份：

```bash $ cp -r calculator/ calculator_v1.1/ ```

经过几个月甚至几年的迭代，你的备份目录可能变成了这样：

``` backups/ ├── calculator_v1.0/ ├── calculator_v1.1/ ├── calculator_v1.2/ ├── calculator_v1.2.1/ ├── calculator_v1.2.1_fixed/ ├── calculator_v1.3_final/ ├── calculator_v1.3_final_real/ ├── calculator_v1.3_final_actually_use_this/ ├── calculator_v1.4_beta/ ├── calculator_v1.4_stable/ └── calculator_v1.4_stable_march_15_backup/ ```

看到这样的目录结构，你或许会心一笑，因为这可能是每个开发者都曾经历过的真实场景。手动备份法在短期内看似简单直接，但随着项目规模的扩大和时间的推移，它的弊端逐渐暴露出来。

手动备份带来的第一个问题是版本管理的混乱。当你拥有几十甚至上百个备份目录时，想要弄清楚哪个目录对应哪个功能、哪个版本修复了哪些bug，几乎是不可能完成的任务。你可能需要打开每个目录，逐个检查文件内容，才能确定这就是你需要的版本。第二个问题是磁盘空间的浪费。每个备份都是完整目录的复制，即使只修改了一个文件，也要复制整个项目。对于大型项目来说，这会迅速消耗宝贵的存储空间。第三个问题是协作的噩梦。如果两个开发者需要同时工作，他们只能通过电子邮件、U盘或者共享文件夹来交换代码。当两人分别修改了不同部分时，手动合并几乎不可避免；当两人同时修改了同一部分时，判断应该保留谁的版本就成了一场博弈。第四个问题是无法追踪变更的细节。你或许知道v1.3版本比v1.2多了什么功能，但具体改动了哪些文件的哪些行，这些信息早已丢失在时间的长河中。

正是这些切肤之痛，推动着人们去寻找更好的解决方案。版本控制系统就是在这样的背景下应运而生的。

早期版本控制工具

SCCS：版本控制的萌芽

1972年，Marc Rochkind在贝尔实验室开发了SCCS（Source Code Control System），这是世界上第一个正式意义上的版本控制系统。SCCS的出现标志着软件开发从手动管理时代迈入了系统化管理时代，尽管这种系统还很初级，但它奠定了许多至今仍在使用的核心理念。

SCCS的工作方式相对简单：它为每个需要追踪的文件创建一个对应的`.s`文件（通常称为SCCS文件），这个文件中不仅保存了文件的当前内容，还包含了所有历史版本的差异信息。当你首次将一个文件纳入SCCS管理时，系统会记录文件的初始版本；当你修改文件并提交新版本时，SCCS只存储本次修改相对于上一个版本的差异（delta），而不是完整的文件副本。这种增量存储的方式大大节省了磁盘空间，也为后来所有版本控制系统所沿用。

使用SCCS的基本工作流程是这样的：

```bash

首次将文件纳入版本控制

$ admin -i calculator.c s.calculator.c

从SCCS文件中取出文件进行编辑

$ get s.calculator.c

编辑完成后，将新版本提交到SCCS

$ delta s.calculator.c ```

`get`命令用于从SCCS文件检出（check out）文件供编辑使用，`delta`命令则用于将修改后的内容作为新版本存入SCCS文件。SCCS还引入了锁的概念：一个文件被检出后会被锁定，其他人在此期间无法检出同一个文件进行修改，这避免了同时编辑导致的冲突。

SCCS在贝尔实验室内部获得了广泛使用，但它有一个显著的局限性：它只能管理单个文件，无法追踪文件之间的关系，也无法处理目录结构的变化。此外，SCCS是专有软件，只在Unix系统上运行，这些因素都限制了它的传播范围。

RCS：个人版本控制的选择

1985年，Walter Tichy在普渡大学开发了RCS（Revision Control System），这是对SCCS的直接改进。RCS保留了SCCS的核心思想——增量存储、SCCS文件格式、锁机制——但做了大量实用性的改进：RCS是完全开源的软件，可以在多种Unix系统上运行；RCS的命令行界面更加友好，错误提示更加清晰；RCS还支持更灵活的工作方式，比如可以检出旧版本进行比较。

RCS的基本使用流程与SCCS类似，但语法更加直观：

```bash

将文件纳入RCS管理（首次需要初始化）

$ ci calculator.c # ci = check in，存入RCS $ rcs -i calculator.c # 初始化RCS文件

检出文件进行编辑

$ co calculator.c # co = check out，检出文件

编辑完成后检出锁定，提交新版本

$ co -l calculator.c # 检出并锁定 $ vim calculator.c # 编辑文件 $ ci calculator.c # 提交新版本 ```

RCS文件通常命名为`filename,v`（在Unix中，`v`后缀表示版本库文件）。与SCCS类似，RCS也采用增量存储方式，通过单向的差异链来保存文件的历史版本。

RCS的一个典型应用场景是个人开发者管理自己的代码仓库。在分布式版本控制系统出现之前，如果你是一个独立工作的程序员，RCS是一个轻量级的选择。你可以在本地为每个项目创建RCS目录结构，追踪自己代码的每一次修改。即使后来转向了更现代的版本控制系统，RCS中保存的历史记录仍然可以导入到新系统中继续使用。

然而，RCS和SCCS一样，都只能管理单个文件，无法处理项目级别的操作。它们假设每个开发者都在本地维护自己的RCS文件库，如果需要协作，开发者必须手动交换RCS文件并合并修改——这在单人项目中还算可行，但在团队环境中就变得非常繁琐。这些局限性催生了下一代的版本控制系统。

集中式版本控制时代

CVS：开源协作的先驱

1990年，Dick Grune在一系列Perl脚本的基础上开发了CVS（Concurrent Versions System），这是第一个真正意义上的协作式版本控制系统。CVS的核心创新在于引入了中央仓库（Central Repository）的概念：所有开发者都连接到同一个服务器，从这个共享的位置检出和提交代码。这样一来，团队中的每个人都能够看到彼此的工作成果，代码变更的历史被集中保存在一个地方，便于统一管理和审计。

CVS的工作架构可以用下面的图示来说明：

R -->|代码同步| A R -->|代码同步| B R -->|代码同步| C ```

在CVS中，开发者首先需要从中央仓库检出（check out）一个工作副本（working copy）。这个工作副本是你在本地进行开发的地方，你可以自由地修改文件，而不会影响中央仓库中的代码。完成修改后，你将变更提交（commit）回中央仓库，其他开发者可以通过更新（update）操作获取你提交的变更。

CVS使用模块（module）的概念来组织相关的文件和目录。一个模块对应仓库中的一个目录树，你可以通过模块名来检出整个项目。典型的CVS工作流程如下：

```bash

检出模块到本地

$ cvs checkout myproject

进入项目目录

$ cd myproject

编辑文件后，提交变更

$ cvs commit -m "Fixed parsing bug in calculator"

获取其他人的最新变更

$ cvs update ```

CVS还引入了分支（branch）的概念，允许开发者在主线之外开辟独立的工作线。比如当你需要开发一个新功能，但又不希望影响稳定版本的开发时，可以创建一个功能分支，所有相关的提交都在这个分支上进行。当新功能开发完成并经过测试后，可以将分支合并（merge）回主干线（trunk）。

CVS在2000年代初期成为开源项目的事实标准，Apache、Linux内核早期都使用CVS进行开发。它的成功主要归功于几个因素：首先，CVS是开源且免费的产品；其次，它支持跨平台操作，可以在各种Unix系统、Linux甚至Windows上运行；第三，它的网络支持允许分布式团队协作；第四，它的设计相对简单，容易学习和部署。在Subversion出现之前，CVS几乎是每个开源项目和小型软件公司的首选版本控制工具。

然而，CVS也存在一些固有的缺陷。首先，CVS不支持原子提交（atomic commit），这意味着当你提交多个文件的修改时，如果提交过程在中途失败，部分文件可能已经被提交，部分文件保持未提交状态，这会导致仓库的不一致。其次，CVS对二进制文件的处理非常低效，每次提交都会完整存储二进制文件的新副本，而不是像处理文本文件那样只存储差异。第三，CVS的分支和合并功能非常薄弱，合并时经常出现冲突，而且合并后很难追踪分支的来源。第四，CVS跟踪的是文件的变更，而不是目录结构的变化，当你在仓库中移动或重命名文件时，历史记录可能会丢失。

SVN：CVS的完美继承者

2000年，CollabNet公司启动了Subversion项目（通常简称为SVN），目标是为CVS的用户提供一个更好的替代品。Subversion由C. Michael Pilato、Ben Collins-Sussman和Brian Fitzpatrick设计开发，2004年发布1.0版本，迅速取代CVS成为新一代的版本控制标准。

Subversion在设计上刻意保持了与CVS的相似性，使得CVS用户能够以最小的学习成本迁移到Subversion。Subversion的命令行界面与CVS非常接近，大多数CVS命令在Subversion中都有对应的等价物：

| CVS命令 | Subversion命令 | 功能说明 | |---------|---------------|----------| | `cvs checkout` | `svn checkout` | 检出工作副本 | | `cvs update` | `svn update` | 更新到最新版本 | | `cvs commit` | `svn commit` | 提交修改 | | `cvs add` | `svn add` | 添加文件或目录 | | `cvs remove` | `svn delete` | 删除文件或目录 | | `cvs diff` | `svn diff` | 查看差异 | | `cvs log` | `svn log` | 查看提交历史 |

但Subversion在底层做了大量改进，解决了CVS的许多痛点。第一个重大改进是支持原子提交。在Subversion中，一个提交操作要么完全成功，要么完全失败，不存在部分提交的情况。这保证了仓库的完整性和一致性，也使得事务的概念得以在版本控制中正确实现。第二个改进是对目录版本的控制。CVS不跟踪目录的变化，而Subversion将目录也视为一种文件类型，可以记录目录的添加、重命名和删除操作。这意味着当你在项目中移动或重命名文件时，Subversion会保留完整的历史记录。第三个改进是对二进制文件的优化。Subversion对二进制文件采用更智能的存储策略，使用二进制 diff 算法来存储增量，减少了存储空间的占用。

Subversion还引入了几个CVS完全没有的重要功能。属性（property）系统允许用户为文件和目录附加元数据，比如可以为所有源代码文件设置`svn:eol-style`属性来统一换行符格式。轻量级复制（cheap copy）功能使得创建分支和标签变得非常高效——在Subversion中，分支和标签只是仓库中某个路径的引用，创建它们的代价几乎为零，不像CVS那样需要复制整个文件树。

Subversion的仓库结构通常遵循一种约定俗成的布局：

``` /project /trunk # 主开发线，稳定代码 /branches # 功能分支、发布分支等 /tags # 标记版本（只读快照） ```

当你需要创建分支时，只需要使用`svn copy`命令：

```bash $ svn copy http://repo/project/trunk \ http://repo/project/branches/feature-x \ -m "Create branch for new feature" ```

Subversion的分支合并功能也比CVS强大得多。`svn merge`命令可以跟踪合并历史，避免重复合并相同的变更。它还支持多种合并策略，包括精确合并（cherry-pick merge）和完整合并（ reintegrate merge），可以根据不同的场景选择合适的方式。

在网络层面，Subversion支持多种访问协议：

```bash

直接访问本地仓库（file协议）

$ svn checkout file:///var/svn/repo/myproject

通过SVN协议访问（需要svnserve服务器）

$ svn checkout svn://server.com/repo/myproject

通过SSH隧道访问（svn+ssh协议）

$ svn checkout svn+ssh://server.com/repo/myproject

通过HTTP/HTTPS访问（需要Apache和mod_dav_svn）

$ svn checkout https://server.com/repo/myproject ```

其中，通过Apache和mod_dav_svn模块提供的HTTP/HTTPS访问方式最为流行，因为它可以利用Apache的认证和授权机制，便于与企业的LDAP或Active Directory集成，同时也便于通过反向代理进行访问控制。

在2005年到2015年的十年间，Subversion是企业级项目的主流选择。许多大型组织至今仍在使用Subversion管理他们的代码资产。虽然近年来Git的崛起使得Subversion的市场份额持续萎缩，但Subversion的稳定性和易用性仍然值得肯定。对于习惯了集中式版本控制、团队成员技术背景多样、或者代码仓库需要严格审计追溯的组织来说，Subversion仍然是一个合理的选项。

分布式版本控制革命

分布式架构的崛起

2005年是版本控制史上具有里程碑意义的一年。就在那一年，Git、Mercurial和Bazaar三个分布式版本控制系统相继诞生，掀起了版本控制领域的一场革命。这不是巧合，而是软件开发规模化和互联网协作模式变革共同作用的结果。

要理解分布式版本控制系统的设计初衷，我们需要回顾集中式系统的局限性。在CVS或Subversion这样的集中式系统中，所有代码都存储在一个中央服务器上，每个开发者从这台服务器检出工作副本。如果服务器宕机或者网络连接中断，开发者就无法提交代码、查看历史，也无法与其他团队成员同步。虽然开发者可以在本地继续工作，但所有提交都必须等待服务器恢复后才能进行。更严重的是，如果中央服务器的硬盘损坏且没有有效的备份，项目的整个历史记录都可能丢失——这对于任何项目来说都是灾难性的。

分布式版本控制系统（Distributed Version Control System，DVCS）从根本上改变了这种架构。在DVCS中，每个开发者的机器上都拥有完整的仓库副本，包括完整的项目历史。这意味着即使在没有网络连接的情况下，开发者也可以查看完整的提交历史、创建分支、提交代码。所有这些操作都在本地完成，不需要与任何服务器通信。当网络恢复或需要与他人协作