我们知道，所有的软件项目在整个生命周期中都要经过不断迭代，在一个又一个的新版本中完善自己的功能。开源项目更是如此，一个健康的开源项目，在“集市”模式下接受来自世界各地开发者提交的代码 ，版本更新频率通常更高。如何管理项目的版本更新，是项目开发、维护过程中必须考虑的问题。

在开始我们的故事之前，首先让我们来认识一下版本控制工具。版本控制的核心述求是历史记录查询和实现协同开发。以开源项目来说，在多人协作开发的模式下，每个人都向服务器提交自己的文件，就可能存在着代码被多次修改、替换的风险，但是版本控制能够在每次更新操作后进行相应的记录。一旦发生误操作，开发者能够根据服务器中的版本记录，将项目恢复到出现问题之前的其他版本。因此，借助版本控制技术，软件开发项目可以被分割为若干模块，每个模块并行地进行开发工作，从而有效地提高了整体编程效率。

主流的版本控制工具主要分为两种，即集中式与分布式。

集中式版本控制工具类似网吧的管理系统，所有项目的历史文件与版本信息都存放在服务器上，而客户端就只能保存当前的状态信息。这种所有鸡蛋装在一个篮子里的模式缺点非常明显，一旦服务器损坏，项目所有的历史数据就会丢失，因此需要大规模的安全备份。比较有代表性的集中式版本控制工具有SVN、VSS、CVS等。

分布式版本控制工具最大的特性就是任意客户端之间可以互联，当然也包括服务器。这样一来，开发者的客户端本地也存有项目完整的历史记录，当有一个客户端损坏时，可以从另一个没有被损坏的客户端中提取历史数据，恢复之前的状态。在协同开发时，各个客户端之间可以很好地同步开发进度，避免出现重复提交等问题。

毫无疑问，分布式版本控制工具拥有更为先进的理念，其诞生的过程也是得益于网络通信技术的普及与开源社区的蓬勃发展。

我们的故事始于 1991 年，大名鼎鼎的开源项目 Linux 问世，作者 Linus Torvalds 一跃成为 IT 界的大明星，被人们称为天才。由于当时 Linux 社区仍采用传统的集中式版本管理，开发者提交的 patch 都汇集到 Linus 这里，让他肩上的担子很重。

（ Linus Torvalds ）

在项目早期，Linus 以最原始的人力来完成 Linux 版本管理工作，包括逐条细看每个 patch、手动合并开发者提交的代码、更新版本历史信息等。由于这段“痛苦”的经历，Linus 本人曾多次公开吐槽 “代码管理是计算机领域最无趣的事”……

然而随着社区的逐渐壮大，Linux 的系统变得越来越庞大，代码越来越繁杂，继续依靠手动合并代码显然已经不太现实。

1999 年，一家名为 BitMover 的公司发布了一款收费的分布式版本控制软件BitKeeper，BitMover 的 CEO Larry 给 Linux 社区特别提供了一个可以免费使用的版本，期望 BitKeeper 能帮助 Linus 免于陷入不断加重的 Linux 内核管理工作中，但条件是不能解锁这款产品。

Linus 在使用 BitKeeper 之后不久就爱上了它，直言其是“ Best tool for the job ”。BitKeeper 让每个开发者都拥有自己的主副本（ master copy ），完整的副本意味着可以在本地做所有事，而不是所有的 patch 只能提交到服务器（Linus）这里。于是，Linus 可以把一些 patch 的审查工作交给 Liunx 子系统的维护者们，对于比较值得信任的维护者甚至不需要他自己再审查一遍，而他只需要对一些自己不太信任的维护者 “重点关照” 即可。2002 年，Linux 内核主线代码就全面开始使用 BitKeeper。

尽管 BitKeeper 的出现赋予了 Linux 社区更好的协同开发能力，让 Linux 内核的开发效率成倍提高，但其闭源的特性仍然让 Linus 在开源界遭到了一些非议。开源泰斗 RSM 就严厉批评 Linus 不该使用一款非自由的软件来管理世界上最大的开源项目。这些负面的声音也为之后 Linux 与 BitKeeper 的分道扬镳埋下了伏笔。

事实证明，指望一个全球最活跃的开源社区长期使用一个闭源工具似乎不太切合实际，毕竟这里聚集了一批全世界最有能力的程序员。于是，社区内开始出现“需要一个类 BitKeeper 的开源工具”的声音，甚至有实干者已经开始着手实现这件事情。

2005 年，Linus 本人所属公司 OSDL 的老板 Andrew Morton资助的一个项目组开始对 BitKeeper 协议进行反向编译，试图解锁 BitKeeper 以创造出一个类似的开源工具。BitMover 公司很快发现了这一动作，Larry 表示这破坏了免费版 BitKeeper 的许可协议，尽管这件事或许与 Linus 本人无关，但确实严重影响了公司的利益，他们最终决定逐步停止对免费版 BitKeeper 的支持，但会给 Linux 进行工具迭代的时间。

这样的矛盾在早期的商业公司与开源社区之间十分常见，由于此时与开源项目相关的商业模式并不成熟，很多像 BitMover 一样的商业软件公司选择站在开源社区的对立面，以保护自己赖以生存的传统商业模式。这些软件公司被业内称为保守派，尤其是以微软、Oracle、SAP 等为首的大型软件开发商，他们坚持以付费的原则提供专有企业软件，凭借产品的技术壁垒收取高额的许可费。这样的商业模式不仅被追求开放自由的开源社区所唾弃，高昂的软件采购成本也让很多企业的 IT 采购人员头疼不已。

不过，BitMover 的做法在当时来看确实也无可厚非，他们正当地维护了自己的合法权利，挽回了因产品被解锁可能带来的经济损失。但令他们万万没有想到的是，开源社区强大的生产力可以成为他们发展的沃土，也能成为毁灭他们的武器。

失去 BitKeeper 意味着 Linux 需要重新寻找一个分布式版本控制系统，Linus 考察了当时所有的系统，却没有一个能够让他满意。

“ 于是他在邮件列表里发了一封邮件，说自己写了一些代码，准备作为在找到更好的版本管理系统之前的过渡系统。我觉得这似乎是件挺有意思的事情，于是就把代码下载了下来，看了一下发现只有1244行。” 这是目前 Git 的主要维护者、Google 工程师 Junio C Hamano（滨野 纯）在一次采访中的描述。

是的，天才 Linus 只花了 10 天的时间，用 C 语言写了 1244 行代码，这就是如今火遍全球的分布式版本控制系统 Git 的雏形。Linus 把写好的代码发到 Linux 社区的邮件列表里，并邀请社区里的开发者一起来完善它。“ 在一周时间内发生了很多事，不过归纳起来就是 Linux 的内核开发者们听说 Linus 要用个“新玩意”来管理代码，如果那个‘新玩意’太难用的话大家都痛苦，还不如一起想办法把这个东西做好用点。” Hamano 就是收到邮件并首批参与 Git 项目的开发者之一。

据 Hamano 回忆，当时 Linus 考察了市面上所有的版本控制系统，没有一款让他满意的原因是它们都没有代码合并（merge）功能。“ 因为 Linus 只写 C 和 Shell，而 merge 的逻辑实在太复杂，所以他多次发邮件到邮件列表，说要是有人能够用脚本语言实现一个就好了。不过谁也没有上钩。就这么过了一个星期，一直关注邮件列表的我用 Perl 把 Linus 过去多次提到的 merge 算法实现并投到了邮件列表里。这是我第一次有一定规模地向开源项目贡献代码。然而，尽管我详细地写了将近 30 个测试用例以及各种分支条件下应该怎么处理的表格，6 个小时以后 Linus 提交到 master 分支的却是个截然不同的东西。据本人说是想到了更好的办法所以就这么着了。”

虽然听起来有些任性，但 Linus 给出的新方案确实让 Hamano 折服。

对于 merge 功能，BitKeeper 的做法是在 work tree 里基本上只存放自己的文件，而 merge 不发生在这里。merge 时首先会创建一个临时文件夹，在里面展开 merge 结果，发生冲突时就在里面解决，然后提交 commit 并在 work tree 里展开，这样就算 merge 完成了。这个方法很好地解决了协同开发常常遇到的代码冲突问题。类似于把发生冲突的两人关进一个小黑屋，“决出胜负”后的胜利者再进入 work tree 。

而 Linus 决定取消这个临时文件夹，直接在 work tree 上 merge 。具体来说，就是每次提交 commit 之前会生成记录本次提交内容的 index，而这个 index 遵循“三步合并”原则，比如我们有一个共同的版本，你在这个版本的基础上做了一些变更，我在这个版本的基础上做了另一些变更，然后将这两个差分 merge 起来。那么把原始版本、我修改的版本、你修改的版本分别作为 stage1，stage2，stage3 依次添加到 index 里，merge 就算完成了。例如最简单的情况，我和你都没有做出变更，那么 merge 的结果就是没有变更。如果我做了变更而你没有，那么最后得到的就是我变更以后的代码，反之亦然。另外还有一种特殊的情况，就是你和我都做了“相同”的变更。

开源本质上就是大家一起做一个项目，互相 merge 的过程。Git 就是在这样的模式下诞生并日趋完善，成长为全球最主流的开源版本控制系统。而 Linus 做的事情只是花 10 天时间写了 1244 行代码，然后审查大家提交的 merge 。“虽然最早是我做了全部的编码和设计，但之后的维护都由 Hamano 来做，他把 Git 做得更接地气，让所有人都能使用。” Linus 曾在 Google 进行的一次演讲中毫不吝啬地夸赞了社区的伙伴。