本文回顾了从手动压缩包、锁定式管理到分布式协作的软件版本控制演进历程，探讨了 Git 如何在技术危机中诞生并凭借其底层架构逻辑确立了长达二十年的统治地位。
版本控制的历史，其实是一部不断试图解决“如何不丢代码”的斗争史。
在正式的系统出现前，开发者过得相当狼狈。那时候的“版本管理”大概就是把项目打包成 `project-2003-04-15.zip`，然后存进备份目录。大家在周一早晨讨论的不是逻辑，而是“上周二那个压缩包里是不是才是对的版本”。这种 ad-hoc 的方式本质上是极其低效且焦虑的。
后来出现了基于锁（Lock-based）的模式，比如 RCS。你想改文件？先把它锁住，别人就只能等着。这在单机时代没问题，但在协作时代简直是灾难。随后的 CVS 引入了并发编辑，虽然解决了“排队”问题，但它缺乏原子性。如果网络在中途断了，仓库就会处于一种谁也说不清的混乱状态。与此同时，微软系的 Visual SourceSafe 虽然在商业领域流行，却因为数据库频繁损坏，让“定期备份仓库”成了 IT 部门的必修课。
转折点发生在 2005 年 4 月。因为 BitKeeper 撤销了免费授权，Linus Torvalds 在十天内写出了 Git。
Git 的出现不是一种缓慢的演进，而是一次架构层面的降维打击。它把版本控制从“中央服务器”的桎梏中解放出来，变成了分布式模型。每一个 clone 都是一个完整的、拥有完整历史的仓库。这种基于内容寻址（Content-addressed）的存储结构，让数据损坏变得可检测，而不是静默发生。
有网友提到，GitHub 的成功在于它把 Git 的分布式特性包装成了社交化的 Pull Request 工作流，让协作变得“可见且可点击”。
即便在 2026 年，虽然出现了 Sapling 或 Jujutsu 等有趣的挑战者，但 Git 的核心数据模型依然稳如磐石。Git 并不完美，它复杂的指令集常让人抓狂，甚至偶尔也会因为误操作导致代码丢失。但它至少做到了：它把控制权还给了开发者，而不是让开发者去伺候平台。
现在的开发流程，究竟是在利用工具，还是在被工具的惯性裹挟？
