0号舱：回到1995！在没有Git的年代，我们是如何写代码的？

那个年代的程序员，是怎么活下来的？

想象一下这个画面：

凌晨 3 点，你坐在一台奔腾 133 的电脑前，盯着屏幕上密密麻麻的文件夹——项目_最终版、项目_最终版2、项目_真正的最终版、项目_这次是真的最终版_我发誓……

你深吸一口气，准备打开其中一个。鼠标悬停在文件夹上时，你的手在微微颤抖。因为你知道，这 15 个"最终版"里，只有一个是能跑通的，其他的……都是屎山。

更要命的是，你已经完全记不清哪个是哪个了。

这不是段子。在 1995 年到 2005 年那段 Git 尚未诞生的“史前时代”，这幅画面是许多程序员的真实写照。

你可能会问：“等等，那个年代不是已经有 SVN 了吗？”

没错，你说对了！当时确实已经有了像 CVS（更早）和 SVN（2000年诞生）这样的版本控制工具。但现实是，它们对于很多项目来说，要么过于复杂，要么过于集中，要么就是还没来得及普及。结果就是，在那个蛮荒的年代，绝大多数开发者最常用的版本管理方式，依然是最原始、最刺激的——“人肉操作”。

你以为这只是个人开发的小麻烦？等你看完接下来三个真实的故事，就会明白：在一个没有 Git 的世界里写代码，真的能把人逼疯。

场景一：单人开发 - “我杀了我自己”

你，一个90年代的极客，正在你的 486 电脑上用 Turbo C 写一个牛逼的贪吃蛇游戏。

开发日志，Day 1： 你实现了蛇的移动，感觉良好。你把整个项目文件夹复制了一份，命名为 snake_v1_can_move。

开发日志，Day 3： 你加入了吃豆子和计分功能，太牛了！你再次复制文件夹，命名为 snake_v2_with_score_backup。

开发日志，Day 5： 你想尝试一个大胆的新功能：让蛇能穿墙。结果，你改了半天，指针满天飞，游戏直接崩溃，蓝屏了。

“没关系，”你想，“我回退到 Day 3 的版本就行。”

你自信地打开 snake_v2_with_score_backup，结果发现……它也是坏的。你突然想起来，后天为了省磁盘空间，你把 Day 3 的备份不小心用今天早上的一个坏档给覆盖了。

你瘫坐在椅子上，感觉身体被掏空。💀 你想回档，却发现存档点早就被自己亲手毁掉了。

这就是第一个，也是最经典的痛点： 【痛点 #1】手动的版本管理，混乱、易错，且极度不可靠。

为了解决这个问题，最早的“守护神”——本地版本控制系统 (LVCS)，如 RCS 出现了。它就像一个自动备份脚本，在你每次保存时，不覆盖旧文件，而是聪明地只记录下**“改动了哪里”**。这让你第一次拥有了真正的“读档”能力，但仅限于你自己的电脑。

场景二：双人协作 - “战争迷雾”

你的贪吃蛇火了，找来了队友小美帮你写双人对战模式。你们公司很大方，给你们配了一个“局域网共享文件夹”。

你们约定好，你负责蛇1，她负责蛇2。

周一： 你俩从共享文件夹把最新代码 snake_v3 拷到自己电脑。你写了一天，实现了蛇1的控制。下班前，你把你的版本覆盖回了共享文件夹。

周二： 小美来了，她看到 snake_v3 更新了，就把它拷到自己电脑。她也写了一天，实现了蛇2的控制。下班前，她也把她的版本覆盖回了共享文件夹。

周三： 你兴冲冲地来到公司，从共享文件夹拷下最新代码，准备整合测试。结果你傻眼了：你昨天写的蛇1控制代码，全没了！

你怒气冲冲地跑去找小美，小美委屈地说：“我昨天拷代码的时候，就没看到你写的蛇1啊？”

你们这才明白，周二早上，小美是在你周一修改前的版本上开始工作的。她的“存档”，覆盖了你的“存档”。你们俩，就像在“战争迷雾”里隔空打仗，互相看不见对方的动向，直到最后兵戎相见，才发现，你方水晶基地，竟是被自己人给推平的。

【痛点 #2】没有统一的“真理”，代码合并变成了一场猜谜游戏和灾难。

为了驱散迷雾，集中式版本控制系统 (CVCS)，如 SVN，闪亮登场。它的核心思想很简单：建立一个“代码中央塔”。

SVN 规定：

所有人都必须先从“中央塔”下载（update）最新代码。
写完后，必须提交（commit）回“中央塔”。
如果有人在你提交前已经提交了新版本，SVN 会拦住你，强制你先更新、解决冲突，然后再提交。

SVN 像一个严格的交通警察，彻底解决了“互相覆盖”的混乱问题，让团队协作第一次变得可能。

场景三：团队壮大 - “中央塔的暴政”

公司上市了，你的贪吃蛇项目组扩张到了100人，遍布全球。SVN “中央塔”的弊端也开始显现。

问题A：断网=失业 你在去总部开会的火车上，想利用通勤时间提交一个重要的 bug 修复。你打开笔记本，敲下 svn commit，屏幕无情地显示：“错误：无法连接到中央仓库”。你不仅无法提交，甚至连查看过去的历史记录、对比两个版本的差异都做不到。因为所有“历史账本”都远在天边的“中央塔”里。没有网，你就相当于一个断了线的风筝。

问题B：分支=天价 你想尝试一个实验性的新功能，比如给蛇加上“激光眼”。最安全的做法是创建一个“分支”，在一个独立的环境里开发。但在 SVN 里，创建一个分支，意味着要在服务器上把整个项目——几十G的代码——完整地复制一遍！这个过程慢到你怀疑人生，而且极度浪费服务器空间。因此，大家对创建分支都心存恐惧，宁愿在主干道上“贴身肉搏”。

问题C：中央塔倒了... 一天早上，你来到公司，发现所有人都无所事事。一打听，才知道存放 SVN 仓库的服务器，硬盘坏了。管理员说，昨晚的备份也失败了。 整个公司的代码历史，一夜之间，烟消云散。 这可比删库跑路刺激多了，那是整个公司的技术资产，一夜归零。

【痛点 #3】对中央服务器的过度依赖，导致了效率低下、创新受阻和巨大的安全风险。

最终章：导火索、天才的愤怒与Git的诞生

与此同时，地球的另一端，一个叫 Linus Torvalds 的男人，正被同样的问题折磨得死去活来。他，Linux 操作系统的创造者，维护着当时地球上最庞大、最复杂的开源项目——Linux 内核。

想象一下，成千上万的顶级黑客从世界各地给他发代码，而他用的版本控制工具，就像一个老掉牙的传真机，效率低下还老卡纸。

【趣事 #1：压垮骆驼的最后一根稻草 🔥】

当时，Linus 和内核社区“白嫖”着一个叫 BitKeeper 的商业版本控制系统。它虽然也算分布式，性能比 SVN 好很多，所以大家也就捏着鼻子用了。

好景不长，BitKeeper 的公司发现，有个叫 Andrew Tridgell 的社区大佬（Samba 的作者，也是个神人）试图逆向工程 BitKeeper 的协议。这下可捅了马蜂窝。BitKeeper 公司一怒之下，收回了给 Linux 社区的免费使用权。

这一下，整个 Linux 内核的协作流程，一夜之间瘫痪了。

Linus 的反应？接下来的剧情，堪称经典：他先是尝试沟通，失败后，彻底怒了。他觉得这是一种背叛，开源社区的自由精神被商业利益绑架了。在被 BitKeeper “背刺”，又鄙视市面上所有替代品之后，这位天才做出了一个和他创造 Linux 时一样酷的决定：

“Fk it. I'll write my own.”** (算了，老子自己写一个！)

【趣事 #2：为啥叫“Git”这么个怪名字？🤔】

于是，在2005年4月，Linus 锁在家里，花了大约10天时间，写出了 Git 的第一个版本。

他给这个伟大的工具起名叫什么呢？叫 “Git”。

在英国俚语里，“Git” 的意思大概是“饭桶、废物、讨厌鬼”。

关于这个名字的由来，Linus 本人的解释充满了极客式的幽默。他半开玩笑地宣称：“我是一个自负的混蛋，所以我用自己的名字给所有项目命名。先是 Linux，现在是 Git。” 这种不拘一格、甚至带点叛逆精神的特质，也深深地烙印在了 Git 的设计哲学中。

Git 的设计，就是为了精准地打击上面我们提到的所有痛点。它的核心思想，就是一场彻彻底底的革命：

告别“中央塔”，人人都是“代码档案馆”！ 这正是 Git 与 SVN 的根本区别。

你问“中央塔”是啥？在 SVN 的世界里，“中央塔”就是那台唯一的、存储了项目所有历史记录的服务器。你的电脑上呢？只是一个“工作副本”，仅仅包含某个特定版本的文件快照。你所有的历史查询、版本对比、提交操作，都必须联网去问那座“中央塔”。

而 Git 则彻底颠覆了这个模式。当你 git clone 一个仓库时，你不是只下载了最新代码，而是把整个项目的**“代码档案馆”——从创世之初到现在的每一次提交、每一个分支、每一条历史记录——原封不动地完整复制到了你的本地电脑。**

每个人的电脑，都成了一个功能齐全、独立完整的代码历史博物馆！

这直接带来了三大好处，完美解决了 SVN 的所有痛点：
1. 断网也能嗨，快如闪电 ⚡️：因为完整的历史记录就在你本地，所以几乎所有操作（如查看历史、创建分支、提交代码）都无需联网，在你自己的硬盘上瞬间完成。你可以在飞机上、地铁里疯狂提交 100 次，等有网了，再一口气“同步”给队友。
2. 分支自由，成本为零 🌿：在 SVN 里创建分支，等于在服务器上复制整个项目，又慢又占空间。但在 Git 里，因为历史都在本地，创建一个分支，本质上只是新建一个指向某个提交记录的、轻如鸿毛的“指针”。你可以随心所欲地开上几十个分支做实验，而毫无心理负担。这极大地释放了创造力和尝试的勇气。
3. 安全感爆棚，永不丢失 🛡：SVN 的“中央塔”一旦倒塌，历史就可能灰飞烟灭。而在 Git 的世界里，只要团队中还有一个人的电脑健在，项目的完整历史就安然无恙。因为每个人手里，都握着一份完整的备份。

后记：从“天才玩具”到“宇宙标准”

你可能会以为，故事到这里就结束了。Linus 大神挥一挥衣袖，Git 就自动征服了世界。

NONONO，真实的历史，往往更像一场精彩的“接力赛”。

第一棒：Linus 的“交棒”与“无名英雄” 🏃‍♂️ Linus 是个典型的“创造者”，不是“维护者”。当他把 Git 的核心设计得差不多之后，很快就觉得这事儿“没挑战了”，然后就像甩开一个他刚拼好的乐高玩具一样，开始物色“接班人”。

这个人，就是 Junio Hamano。一位当时在 Google 工作的日本工程师。

从2005年7月起，这位“扫地僧”般的大佬，就接手了 Git 的维护工作，一直持续到今天，超过了15年！我们今天使用的 Git 中许许多多的功能和优化，都出自他和社区的努力。Linus 给了 Git 生命，而 Junio Hamano 则陪着它长大成人。

第二棒：GitHub 的“社交革命” 🚀 Git 本身只是一个命令行工具，一个强大的“引擎”。真正让它飞入寻常百姓家的，是2008年成立的一家公司——GitHub。

如果说 Git 是那台性能炸裂的 V8 引擎，那 GitHub 就是围绕它造出的一辆拥有自动导航、舒适座椅和超大天窗的豪华跑车。

GitHub 做对了三件大事：

可视化界面：它把 Git 复杂的命令，变成了人人都会点的网页按钮。
社交网络：它引入了 Follow（关注）、Star（点赞）、Fork（复制一份到自己名下），让代码仓库第一次有了社交属性。你可以像逛朋友圈一样逛代码，发现好玩的项目就 Fork 一份自己研究。
杀手级应用：Pull Request：这是一个划时代的发明！它让“贡献代码”这件事，变成了一个公开、透明、可讨论的流程。任何人都可以 Fork 一个项目，修改后发起一个 Pull Request（请求合并我的代码），然后项目原作者和其他人可以像审稿一样，逐行 review 你的代码，提出修改意见，最终一键合并。