本章目标

理解为什么我们需要版本控制，以及它如何让你放心大胆地改代码。

一、从一场灾难说起

你正在开发一个项目。昨天代码跑得完美，今天改了几行之后——崩了。你想回到昨天的版本，但 Ctrl+Z 早就失效了。编辑器关闭的那一刻，昨天的状态就永远消失了。

这个问题不只你有。在版本控制出现之前，这是所有程序员的日常困境。

1.1 手动备份：人类最原始的版本控制

直觉反应是手动复制文件夹来"备份"。很快，你的项目目录就变成了这样：

• 论文_初稿.doc
• 论文_修改版.doc
• 论文_最终版.doc
• 论文_最终版_打死不改了.doc
• 论文_最终版_真的最后一次.doc
• 论文_最终版_v2_完整版(1).doc

项目代码同理——文件夹里长满 project_backup_1201、project_v2、project_v2_fixed、project_v2_fixed_final 这样的幽灵目录。

三个致命缺陷

手动备份的操作成本极低，但它背后藏着三个你迟早会踩中的坑：

1. 存储爆炸与信息熵增：改一行代码就得复制整个项目。一个 100MB 的项目，改 20 次就是 2GB。更致命的是，你根本分不清每个副本之间到底有什么差异——文件夹名字是你唯一的"提交信息"，而它基本等于噪音。
2. 无法精确回退：你知道"上周五下午那个版本是对的"，但不知道它到底是 backup_12 还是 v2.3_fix，只能一个一个打开试。
3. 变更历史为零：两个月后回来看代码，你完全不知道某段逻辑为什么长这样、是谁写的、当时在想什么。代码在，但上下文永远丢失了。

圈子里流传着一句话："它能跑就别动它。" 这句话背后的情绪不是懒惰，而是恐惧——对失控的恐惧，对"改坏了改不回去"的恐惧。Git 要解决的，恰好是这份恐惧。

二、版本控制解决什么问题

版本控制系统（Version Control System，VCS）提供了三个核心能力。就三句话：

• 记录（Snapshot）：将项目在某一时刻的完整状态保存为一个版本。每次你主动"拍照"，就生成一个不可篡改的快照。
• 回溯（Rollback）：随时切回历史上的任意一个版本。改崩了？一秒回去，就像什么都没发生过。
• 对比（Diff）：精确告诉你两次版本之间，哪些文件的哪些行被增删改了什么内容。不是靠记忆，不是靠猜。

这三个能力组合在一起，让你获得一种此前不敢想的自由：大胆试错。每一次改动都是可逆的，每一次实验的代价趋近于零。

关键认知

版本控制不是"备份工具"。备份是事后补救，而版本控制是你编写代码的基础设施——它记录的不是最终结果，而是代码演化的完整过程，每一行的来龙去脉。

三、为什么是 Git

版本控制这个领域，历史上出现过不少选手：CVS、Subversion（SVN）、Mercurial（Hg）都曾名噪一时。但今天，Git 是毫无争议的唯一主角。

3.1 Git 诞生记：一段恩怨，一场爆发

2002 年，Linux 内核——人类历史上最大的开源协作项目——面临一个尴尬的问题：它没有一个像样的版本控制工具。

当时的 Linux 社区使用的是一款叫 BitKeeper 的商业版本控制软件。BitKeeper 的创始人 Larry McVoy 出于对开源的善意，免费授权给 Linux 社区使用。看起来是一个温情的合作故事，但它只持续了三年。

2005 年，Linux 社区的 Andrew Tridgell（Samba 的作者）试图通过逆向工程破解 BitKeeper 的协议，写出一个开源的替代品。Larry McVoy 震怒，认定这是对信任的背叛，收回了 Linux 社区的免费许可。

一夜之间，Linux 内核的几千名贡献者没了版本控制工具。

Linus Torvalds 的回应方式堪称传奇。他说了一句后来被刻进程序员文化基因的话：

"Talk is cheap. Show me the code." —— Linus Torvalds

然后他闭关写代码。以下是真实的时间线：

• 第 1 天：构思架构，敲定核心数据模型——有向无环图（DAG）。
• 第 10 天：Git 第一个可用版本问世。从零到能用的版本控制系统，10 天。
• 第 14 天：Git 开始用 Git 管理 Git 自己的源代码——自己吃自己的狗粮（dogfooding）。
• 一个月后：Linux 内核的源代码全面迁移到 Git。

在愤怒中诞生，用代码说话——这很 Linus。

3.2 Git 名字的由来

冷知识：Git 到底是什么意思？

Linus 在 Git 的 README 里亲手写了一段解释，大意是：

"git" 可以表示任何含义，取决于你的心情：

• 一个随机的三字母组合，可发音，没有被 UNIX 命令占用。它是 "get" 的错误发音，这可能有关也可能无关。
• 蠢货、讨厌鬼。从英国俚语词典里随便挑。
• "Global Information Tracker"：当你心情好、它又正好在正常工作的时候。天使歌唱，光芒洒满房间。
• "Goddamn Idiotic Truckload of sh*t"：当它崩了的时候。

简单说：Linus 用英国俚语里"混蛋、蠢货"的意思自嘲。反正他给 Linux 命名也是用自己的名字——这种自嘲和自信的混合，是典型的 Linus 风格。

3.3 Git 凭什么赢了

Git 不是第一个分布式版本控制系统，但它有三个决定性优势：

• 分布式架构：每个人的电脑上都是一个完整仓库，包含全部历史记录。断网照常 commit、照常看日志、照常回退。SVN 断网就只能对着天花板发呆——它是集中式的，一切操作依赖服务器。
• 快照式存储：绝大多数 VCS 采用基于文件的增量存储（delta-based），每次提交记录的是"改了哪些行"。Git 是快照存储——每次提交保存所有文件的完整状态快照，未改动的文件只存一个引用。这让分支的创建和切换快如闪电。
• GitHub 的网络效应：2008 年 GitHub 上线，把 Git 从一个"Linux 社区的工具"变成了"全世界的协作平台"。Pull Request、Issue、Fork——这些机制围绕 Git 生长出了一个社交化的编程生态，让 Git 的护城河深不可测。

扩展阅读：Subversion 和 Mercurial 后来怎么样了？

• Subversion（SVN）：Git 出现前是企业级 VCS 的代名词，大部分公司的"正规军"都用它。GitHub 上线后使用率断崖式下跌。Apache 基金会至今仍在维护，但新项目几乎不会再选用。它的死穴是集中式架构——服务器挂了，全世界停工。
• Mercurial（Hg）：和 Git 同年（2005）诞生，分布式架构相似，设计思路甚至比 Git 更优雅、更易学。2010 年前后在 Google、Facebook 内部大量使用。2014 年起生态逐渐萎缩，2019 年 Bitbucket 宣布停止支持 Mercurial，标志着它正式退出历史舞台。它的败因不是技术差，而是 Git + GitHub 的组合太强了——网络效应碾压了纯技术优势。

3.4 Git 的行业地位

今天，Git 已经是所有程序员的基础技能：

• GitHub（2018 年被微软以 75 亿美元收购）是全球最大的代码托管平台，拥有超过 1 亿开发者。
• 从 Google 到三人创业团队，从个人博客到 Linux 内核——全在用 Git。
• Git 的使用范围早已超出代码：书籍写作（GitBook）、法律文件版本管理、甚至建筑设计图纸——任何文本文件需要版本管理的地方，Git 都是最优解。

学会 Git，不是你简历上的加分项，而是进入这个行业的入场券。

总结

Git 是你代码的时光机。有了它，"改崩了"不再意味着灾难，只是一次 git reset 的距离。它把"不敢动代码"的保守，变成了"大不了回退"的自信。