回顾 Linux 内核开发者多年来使用的各种版本控制解决方案、Linus Torvalds 决定使用 BitKeeper 以及随之而来的争议，以及 Git 如何被创造出来。

最初，Linus Torvalds 根本不使用版本控制。内核贡献者会将他们的补丁发布到 Usenet 群组，后来发布到邮件列表，Linus 会将它们应用到他自己的源代码树中。最终，Linus 会发布整个代码树的新版本，补丁之间没有任何区分。检查其过程历史的唯一方法是查看两个完整版本之间的巨大 diff。

这并不是因为当时没有可用的开源版本控制系统。CVS 自 20 世纪 80 年代就已出现，并且仍然是最流行的系统。它的核心功能是允许贡献者向中央仓库提交补丁，并检查进入该仓库的补丁的历史记录。

尽管如此，人们对 CVS 有很多抱怨。其中之一是它按文件跟踪更改，并且不将较大的补丁识别为单个修订，这使得解释其他开发人员过去的贡献变得困难。还存在一些难以修复的错误，例如当两个冲突的补丁同时提交时出现的竞争条件。

Linus 不喜欢 CVS，部分原因与其他人的理由相同，部分原因则出于他自己的原因，这些原因稍后才会变得清晰。他也不喜欢 Subversion，这是一个在 21 世纪初出现的开源项目，其具体目标是解决 CVS 中的错误和缺陷。

许多 Linux 内核开发者对缺乏适当的版本控制感到不满，因此一直存在一定的社区压力，希望 Linus 从现有选项中选择一个。然后在 2002 年，他选择了。令所有人震惊和沮丧的是，Linus 选择了 BitKeeper，这是一个由 BitMover 公司开发的闭源商业系统，该公司由 Larry McVoy 运营。

Linux 内核是历史上最重要的开源项目，而 Linus 本人是第一个发现开源开发技术的人，这种技术避开了 GNU 项目，并将被开源项目模仿数十年，直到今天。Linus 在想什么？他怎么能像这样背叛他的社区和开源世界？当 Linus 首次开始使用 BitKeeper 进行内核开发时，许多人都有这些想法。

此外，BitMover 为了换取非付费许可证，对 Linux 社区施加了重大限制。首先，Linux 开发者在使用 BitKeeper 时，不得从事竞争性版本控制项目的工作。其次，BitMover 将控制与内核项目相关的某些元数据，以便注意到任何滥用许可证的行为。如果没有访问这些元数据的权限，内核开发者将无法比较过去的内核版本——这是其他版本控制系统的重要标准功能。

争议并没有平息，尽管 Linus 多年来一直依赖 BitKeeper。他的基本论点是，他不是一个自由软件狂热者。如果开源工具比商业同类产品更好，他就会使用开源工具。但如果商业工具更好，他也不会嗤之以鼻。

然而，许多内核开发者确实是自由软件狂热者。Linus 与其他开发者之间的愤怒和紧张关系十分强烈，但这不足以分裂社区并导致 Linux 内核项目的实际分支。当然，像 Alan Cox、Al Viro、David Miller、Andrea Arcangeli、Andrew Morton 和相当多其他人拥有领导竞争项目的技术技能，甚至可能有些人拥有足够的声望来吸引大量内核开发者。但没有人这样做。紧张和敌意持续存在。

BitKeeper 的主要声誉在于它提供了一个分布式系统，整个仓库可以轻松地 fork 和合并。这是关键。有了它，内核开发者子组可以独立协作，并受益于版本控制，然后在准备就绪时将他们的更改反馈给 Linus。这样，以前完全堆积在 Linus 肩膀上的大部分工作可以分配给他的受信任的副手，或者实际上分配给任何选择以这种方式协同工作的团队。架构、驱动程序和子系统都可以相对独立地开发，然后每个都可以一次性合并到主内核树中。

这一切可能听起来很熟悉，但在 2002 年，这是一个新想法。像 CVS 和 Subversion 这样的现有项目只能将 fork 和合并作为主要的、耗时的操作来完成，这会让你渴望死亡。有了 BitKeeper，它变成了一个微不足道的操作。

Linus 愿意在内核开发工具链的核心使用专有软件，这激励了很多人更加努力地创建替代方案。CVS 和 Subversion 项目已经远远落后，并且犯了太多基本的设计错误。其他现有项目也是如此。但是现在每个人都知道——或者认为他们知道——Linus 真正想要什么，他们就可以开始认真编码了。结果是出现了许多提供分布式开发的版本控制系统。

其中有 arch、darcs 和 monotone。以 BitKeeper 为竞争模型，它们各自代表着为 Linus 提供 BitKeeper 替代方案的努力。

许多人尝试了，但没有人成功。部分原因是 Linus 不会完全阐明他对这些项目中的任何一个的需求，正如他没有完全阐明 CVS 和 Subversion 缺少什么一样。还有一种感觉是，Linus 并不介意使用闭源工具——对于他来说，任何可接受的替代方案都必须在技术上比 BitKeeper 有显着改进。因此，即使在 BitKeeper 出现之前，没有哪个开源工具足够好，但 BitKeeper 的出现进一步提高了任何可能出现的开源工具的门槛。

经过三年的努力，没有一个开源替代方案比 CVS 或 Subversion 更接近满足 Linus 的需求。如果不是 Andrew Tridgell，Samba 的创建者、rsync 的共同创建者以及一位乐于助人的好人，这种情况可能会持续更长时间。2005 年，Andrew 试图逆向工程 BitKeeper 网络协议，以便创建一个自由软件替代方案。即使不是他，也会是其他人——这只是时间问题。Larry McVoy 曾警告 Linux 开发者，如果有人尝试这样做，他会拔掉插头，而他正是这样做的。突然之间，BitKeeper 不再能用于内核开发。整个开发工具链，以及围绕分布式版本控制而兴起的开发者文化，都陷入了不确定性。

这意味着什么？Linus 会回到他旧的开发风格，自己审查所有补丁吗？如果不是，他会选择 BitKeeper 的开源替代方案之一吗？如果他选择了，会是哪一个？

在这一点上，发生了一件非凡的事情。自 1991 年成立以来，Linus 首次完全停止了 Linux 内核的工作。由于没有现有工具可以满足他的需求，他决定自己编写一个。

事实上，Linus 主要关心的问题之一是速度。这是他以前从未完全阐明过的，或者至少没有以现有项目可以理解的方式阐明过。随着全球数千名内核开发者全力以赴地提交补丁，他需要一些能够以以前从未想象过的速度运行的东西。即使对于最大和最复杂的操作，他也不能等待超过几秒钟才能完成。arch、darcs、monotone 以及任何其他项目都从未接近满足这一要求。

Linus 隐居了一段时间进行编码，然后与世界分享了他的新构想。在 2005 年 6 月开始该项目的几天内，Linus 的 git 版本控制系统就实现了完全的自托管。几周内，它就准备好托管 Linux 内核开发。几个月内，它就实现了全部功能。此时，Linus 将该项目的维护权交给了最热情的贡献者 Junio C. Hamano，并再次全职投入到 Linux 开发中。

一个震惊的自由软件开发者社区努力理解这个奇怪的创造物。它不像任何其他版本控制软件的尝试。事实上，它看起来更像是一堆底层文件系统操作，而不是版本控制系统。而且，它没有像其他系统那样存储补丁，而是存储每个更改文件的完整版本。这怎么可能好呢？另一方面，它可以闪电般的速度处理 fork 和合并，并且可以根据需要快速生成补丁。

渐渐地，Junio 汇集了一组更高级别的命令，这些命令更接近 CVS 和 Subversion 等工具的命令。如果最初的 git 命令集是“管道”，那么这组新命令就是“瓷器”。因此，它们就被这样称呼了。

就像人们对 BitKeeper 存在争议和不满一样，人们对 git 的进一步开发也充满了热情和参与。端口、扩展和网站遍地开花。在几年之内，几乎每个人都使用 git。就像 Linux 一样，它征服了世界。