4 月 7 日，全球最主流的管理辅助工具系统 —— Git 迎来 15 十周年国庆日，工程项目主要贡献者 Junio C Hamano（滨野 纯） 先生发送信息欢庆了这一日子。
他们知道，大部份的应用软件工程项目在整个生命周期中都要经过不断插值，在两个又两个的新版中完善自己的功能。开放源码工程项目亦然，两个健康的开放源码工程项目，在“市集”商业模式下接受来自全世界合作开发人员递交的标识符 ，版预览振幅通常更高。如何管理工程项目的版预览，是项目合作开发、维护操作过程中必须考虑的难题。
什么是管理辅助工具辅助工具
在开始他们的故事以后，首先让他们来哥们管理辅助工具辅助工具。管理辅助工具的核心述求是历史记录查阅和实现协同合作开发。以开放源码工程项目来说，在多人协同合作开发的商业模式下，每一人都向伺服器递交自己的文档，就可能存在着标识符被多次修改、代替的风险，但是管理辅助工具能在每次预览操作后展开相应的历史记录。
除非发生错误操作，合作开发人员能根据伺服器中的版历史记录，将工程项目恢复正常到出现难题以后的其他版。因而，借助于管理辅助工具技术，应用软件合作开发工程项目能被拆分为若干组件，每一组件博戈达地展开合作开发工作，从而有效地提高了整体程式设计效率。
主流的管理辅助工具辅助工具主要分为两种，即封闭式与分布式系统。
封闭式管理辅助工具辅助工具类似出租房的管理系统，大部份工程项目的历史文档与版信息都存放在伺服器上，而应用程序就只能保存当前的状况信息。这种大部份猪肉装到两个箱子里的商业模式优点较为明显，除非伺服器损毁，工程项目大部份的历史经验就会遗失，因而需要大规模的安全存储。比较有指标性的封闭式管理辅助工具辅助工具有 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 的做法在当时来看确实也无可厚非，他们正当地维护了自己的合法权利，挽回了因产品被破解可能带来的经济损失。但令他们万万没有想到的是，开放源码街道社区强大的生产力能成为他们发展的沃土，也能成为毁灭他们的武器。
用开放源码的方式创造 Git
失去 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 行标识符，然后审查大家递交的 patch 。
“虽然最早是我做了全部的编码和设计，但之后的维护都由 Hamano 来做，他把 Git 做得更接地气，让大部份人都能使用。” Linus 曾在 Google 展开的一次演讲中毫不吝啬地夸赞了自己的伙伴。
（图右为 Junio C Hamano）
作为开放源码工程项目的管理者，Linus 不仅是个智商超群的程式设计天才，他的管理情商也很高。在维护两个开放源码工程项目时，对别人说“No”是家常便饭。
不合适”，同时还会指出 commit 中的亮点并给予肯定，让对方觉得自己的工作没有白费，这样就不会打击贡献者的热情。“ 我那时候也是，Linus 对我说，虽然你的递交没有采用，但测试用例还是能用的，针对现在的实现你稍微修正一下吧。” Hamano 回忆说。
在 Hamano 等人的协助下，Git 问世近两个月后，Linux 系统的源码就全部改用 Git 展开版管理，而其他的开放源码工程项目街道社区也如获至宝，Git 的名气很快就在开放源码界传播开来。
截然不同的命运
2008 年，基于 Git 实现的标识符托管平台 GitHub 面世，从此 Git 更是享誉全球。有意思的是，GitHub 当初并不是由 Git 街道社区的人做的，而是出自 Ruby 街道社区的合作开发人员之手，两个街道社区在最初的关系还有些不太和睦，原因是 Git 街道社区的人对于 GitHub 那群人拿 Git 去做商业化感觉很不爽……当然，这些都是老合作开发人员口中的陈年往事了。众所周知，GitHub 对于 Git 的普及化做出了巨大的贡献。Hamano 也表示：“ 有 GitHub 替他们做文档以及用户支持，何乐而不为呢。”
和 Git 的飞速发展形成鲜明对比的是，与 Linux 决裂后的 BitKeeper 每况愈下，尽管后者是世界上首个商用级的分布式系统管理辅助工具辅助工具，但在 Git 问世之后，BitKeeper 的市场占有率断崖式下滑，几乎沦落到无人问津的地步。Git 与 BitKeeper 的不同境遇能说是 21世纪初应用软件行业的缩影，传统的应用软件商业商业模式在开放源码浪潮的席卷下迎来了前所未有的挑战。
当然，挑战往往伴随着机遇。于是，也有一批人开始反思传统应用软件商业模式的局限性，试图寻找一种能适应开放源码的全新商业商业模式。很快，以 Red Hat、MySQL、SugarCRM 为代表的开放源码行业公司开始崛起，他们的商业商业模式是利用开放源码工程项目来推出增值服务，即免费向用户提供软
比如 Red Hat 在 RHEL 推出的订阅服务，在用户免费使用这款企业级 Linux 系统的前提下，他们能通过订阅，获得每一版产品一定时间内的技术服务支持。这种支持包括但不限于系统升级、管理、维护；安全性和技术认证支持；其他硬件和应用软件支持。
此外，Red Hat 还通过积极地投身开放源码街道社区为品牌赢得业内认可，从而促进其他收费产品的销售。自 2001 年确立商业商业模式以来，Red Hat 已经实现连续 19 个自然年的营收增长，创造了开放源码界的商业巨作。
当 Red Hat 们利用开放源码工程项目取得前所未有的成功之后，许多传统应用软件合作开发商也开始意识到，开放源码已经是无法阻挡的时代趋势。2018 年，曾经的“保守派”代表微软收购 GitHub，进一步布局开放源码；2019 年，蓝色巨人 IBM 斥资 340 亿美元收购 Red Hat，完成公司历史上最大规模的收购……越来越多的应用软件巨头参与到了开放源码街道社区的建设中，积极拥抱开放源码。
值得一提的是，2016 年，在 Git 问世 11 年之后，曾经与 Linux 短暂携手的 BitKeeper 宣布开放源码，只可惜为时已晚。
