最近，关于“为什么 GitHub 能够在众多的代码托管平台中脱颖而出”这个问题，引发了广泛的讨论。一些科技博主和行业观察者从不同的角度对这一话题进行了深入的分析。例如，Ping Labs 创始人 Theo Browne 和 Graphite 创始人 Greg Foster 的解读。
作为 GitHub 的联合创始人，我认为写下我自己对 GitHub 崛起并占据主导地位背后原因的看法可能也同样有意思，或许还能纠正一些他们从外部视角所做出的不太准确的分析。
跟他们不一样的是，我亲身经历了这一切。另外，我还写了这本书。
2009 年，我的“Pro Git”第一版开箱。
所以，这是一位内部人士对“为什么 GitHub 会赢”的看法。
如果你想要一个简短的答案，我可以将其归结为两个原因：
-
GitHub 的起步正逢其时
-
GitHub 的品味不错
GitHub 的四位联合创始人，无论是在 GitHub 之前还是之后，都曾经历过失败。Chris 和 PJ 在创立 GitHub 之前没能成功运营 FamSpam，Tom 和我也没有让 Chatterbug 一飞冲天。在我看来，这两个项目都有不错的品味和出色的产品，但或许是时机、地点、市场或其他因素未能使它们达到 GitHub 的高度。
在 GitHub 诞生之初，开源的分布式版本控制工具开始变得实用、稳定，并逐渐被广泛采用，但当时还没有人托管这些工具，更不用说商业应用了。大型托管服务商对此不以为意，小型玩家也不够重视。
此外，那些最后也开始关注这一趋势的玩家（比如 Sourceforge、Google Code 等，在目睹了 Git 和 GitHub 越来越膨胀的人气之后）却显得品味不足。他们永远无法与一个由以产品为中心的开源软件开发者组成的团队所运营的开发者工具公司相抗衡。
我们关心开发者体验，并通过创新打破固有假设，构建我们理想中的工作方式。而其他人则试图构建他们认为能够吸引广告商或 CTO 的产品。
这就是为什么 GitHub 会赢。
如果你对这些背后的故事感兴趣，就让我带你一探究竟，了解这一切是如何发展起来的。
背景
让我们回到故事的起点。
我将从 2005 年前后的软件开发者的视角，深入探讨“GitHub 的起步正逢其时”这一观点。那个时候，Linus 提交了第一个 Git，Olivia 提交了第一个 Mercurial。
很久以前我的 Windows Vista、Ubuntu 和 Mac 桌面。
2005 年的软件开发处于一个怎样的环境？这是 Git 能够赢得人们青睐、GitHub 能够生逢其时的时代吗？
2005 年发布的 Mac OS Tiger。如果你是 Mac 用户，它看起来就像这样。
如果你在 2005 年是一名软件开发人员，很可能（甚至希望）在使用像 Subversion 这样的集中式版本控制系统。在 Git 问世之前，我曾使用过 RCS、CVS、Subversion 和 Perforce。实际上，我在一家公司工作时甚至直接通过 FTP 将 PHP 文件上传到生产服务器。
现在，如果你在开发商业软件，像 SVN 这样的集中式版本控制系统其实并非最糟糕的选择。它简单易用，只需要检出、修改、再检入即可。虽然分支和合并功能非常糟糕，但在许多情况下，基本上可以避免使用这些功能（我甚至不确定自己是否曾在 Subversion 或 Perforce 中使用过分支功能）。
坦白说，现在人们对 Git 的抱怨可能比当时对 SVN 的抱怨还要多——SVN 的用户界面和使用体验可以说比 Git 更简单。
Perforce 2005.1 可视化客户端。我忍受了它很长时间。
我认为，在这一时期开始显现的问题并不局限于封闭的开发团队，真正的挑战在于不断壮大的开源世界。与今天相比，开源在那个时期几乎微不足道。你们这些年轻人可能不记得那个没有数百万开源项目的年代，直到“开源”这个词在 1998 年被创造出来。
Dirk Riehle 等人在 2008 年发表了一篇论文，分析了当时全球开源项目的趋势，他们估计当时全球大约有 18000 个活跃的开源项目——可想而知，2005 年时这个数字肯定更少。
开源项目的总数。来自 2008 年 Amit Deshpande 和 Dirk Riehle 发布的“开源项目总体增长”。
相比之下，如今仅在 GitHub 上就有超过 2.8 亿个公共代码库。
那么，开源是如何推动 Git 和 GitHub 时代的到来？
因为开源正在迅速发展，而集中式版本控制系统在开放式贡献策略方面表现尤其糟糕。换句话说，你无法很容易地公开共享一个项目，然后再以简单的方式将贡献合并回项目中。
2005 年的开源贡献
当时的情况到底有多糟？我们可以通过 Subversion 进行开源贡献的经历来看看。
在 Subversion 时代，想要为一个开源项目贡献代码是非常麻烦的一件事。Subversion 服务器通常设置成未经身份验证的用户只读，这就意味着如果你想参与贡献，必须先将整个项目代码检出到本地，然后才能进行修改。修改完成后，你还需要手动生成补丁文件，再通过项目的工单系统或邮件列表提交给维护者。
然后维护者需要拉取补丁文件，然后将补丁应用到他们的项目中，看看是否可以正常应用或是否正常工作，最后再提交反馈，做出更改，或提交更改。
网上仍然有这种“遗迹”。我曾在某个时候使用过 Trac 来处理这种类型的项目，你仍然可以看到他们补丁提交指南和一个变更建议工单。
Ruby on Rails 项目，以及我的朋友（也是 GitHub 后来的联合创始人）使用了一个类似的工单系统，叫作 Lighthouse（令人难以置信的是它至今仍然存在）。我最早的开源项目之一是一个叫作 git-lighthouse 的命令行工具，它可以简化从工单系统中拉取和应用补丁的过程。
这个过程如此繁琐，以至于当有工具出现来简化它时，就迅速被广泛采用。而那个工具就是 GitHub。但在此之前，我们需要 Git。
Git 的崛起
Git 的诞生实际上是源于 Linus Torvalds 非常喜欢的一个（当时）商业版本控制系统 BitKeeper。它最初是为了帮助简化操作系统内核开发流程而设计的。
如果 BitKeeper 是开源的，或者拥有更友好的许可条款，可能就不会有 Git 或 GitHub 什么事了。
然而，当时的实际情况是，一位 Linux 开发者对 BitKeeper 的协议进行了逆向工程，违反了许可条款。随后，BitKeeper 和 Linus 之间发生了争执，双方都认为这种争执是不可接受的，于是决定分道扬镳。
Linus 借鉴了 BitKeeper 的一些启发性的概念，拼凑出了他认为能解决自己问题的最简单的工具，并将其命名为 Git，这个“来自地狱的信息管理器”。
它很快就被 Linux 社区的一些人采用，并慢慢发展成为一个版本控制系统。
当时的 Git 让人感觉很棒，有这几个原因：
- 分支和合并是梦想而不是噩梦
- 速度很快
- 权限管理更简单
在 Git 的早期，我会在演讲中做一些演示，创建分支、提交更改到分支、切换分支，然后将它们合并，所有这些操作都在 60 秒内完成。我看到人们的下巴都要掉了下来。有些人甚至认为我在做假演示。
我无法形容在 2006 年能够如此快速而轻松地切换和合并上下文是多么令人惊叹。在 Subversion 中，这完全是个噩梦。
Baby Scott 在 RailsConf 2008 大会上谈论 Git
不需要通过网络与中央服务器协商代码提交也令人难以置信，感觉就像是驾驶一艘火箭船，一切都如此之快。
也许更重要的是，你可以非常容易地 fork 代码库，这意味着你可以托管自己的代码库副本，并拥有自己的写入权限，你推送更改，其他人将其拉取到他们自己 fork 的副本中。Linux 项目很早就开始这样做了——对于较大的更改，他们可以发送一个请求，从托管的 fork 副本中拉取更改。
如果你想知道“Pull Request”这个词是怎么来的，这就是它的由来：Git 有一个命令，它会生成并发送一封格式化的电子邮件帮助你简化这个过程。当 GitHub 添加了生成这种类型消息的功能时，我们就决定把它叫作“Pull Request”。如果你还是好奇，可以看看这个。
有些人认为开发者喜欢 Git 是因为它具有分布式特性，克隆代码库时能够得到整个历史记录，并在本地进行分享，等等。我不同意这种看法。我认为几乎没有人真的关心这些。分布式之所以很酷，是因为你可以快速托管完整可写入的 fork 副本，这让权限管理变得简单得多。
它之所以酷，是因为代码贡献从一个谁有权推送的问题变成了谁有有趣的东西可以拉取的问题。
当然，正是这一点直接催生了 GitHub。
GitHub 的崛起
去年年底，我与 Tom（也是 GitHub 联合创始人）进行了一次访谈。在我们讨论的内容中，他分享了他最初是如何想到要做 GitHub 的。
Tom 在 Powerset 工作期间，他的团队开始在内部使用 Git 作为版本控制系统。然而，将其他团队成员加到内部服务器的过程相当繁琐，因为 Git 主要通过 SSH 协议进行通信，这要求在服务器上为每位成员创建具有 SSH 访问权限的账户。这一过程不仅复杂，而且对于大多数团队成员来说也不值得。因此，Tom 萌生了简化这一过程的想法。
Git 很棒，但托管 Git 却很麻烦。这就是 Tom 为什么要做 GitHub 的原因。
为什么要做 GitHub，为了解决痛点。
我翻阅了我的旧邮件，试图找到我第一次听说 Tom 要做“GitHub”项目是在什么时候。结果发现，是 Chris 在 2007 年底回复我关于 Git 屏幕录像制作的邮件中提及的。
当时，这还只是他们两人之间的秘密副业项目。也就是在那时，我开始与 Chris 和 Tom 讨论 Git/Ruby 库，并逐渐融入了这个项目和公司。
他们的“推销”手法有几个有意思的地方。
首先，他们与当时唯一的公共 Git 托管网站 repo.or.cz 进行了对比（值得一提的是，这个网站至今依然奇迹般地在运行），不同的是他们做了一个关键的创新，那就是以用户为中心，而不是以项目为中心。在那之前，如果你想在 Sourceforge 或类似的平台上托管项目，你通常需要抢注一个名字。而在 GitHub 上，你可以自由使用任何你想要的名字，因为项目是直接与你的账户关联的。
其次，他们专注于采用拉取模型而非推送模型（这基本上与我之前讨论的权限问题相关）。
第三，“不丑”是一个核心特性，GitHub 是有“品味”的。
Git 赢了
那么问题来了，为什么是 Git 赢了？那个时期出现了很多分布式版本控制系统。Mercurial 在很多方面都与 Git 很相似，甚至在很多方面都做得更好。为什么是 Git 在伟大的 DVCS 之争中胜出了？
我认为答案与两个东西有关，一个是 Linux（以及 Linus），另一个是 GitHub。
也许是因为 Linus/Linux
Linux 项目使用了 Git，是 Linus 启动了这个项目，并给了它“即时的可信度”。
每个人都知道 Linux，每个人都知道 Linus。既然他可以开发一个每个人都使用的操作系统，当然也有能力开发下一代版本控制系统。即使这个系统可能难以使用，但也许是因为他的智慧超越了我们，所以我们应该更加努力，不是吗？
17 年前，Linus 在谷歌园区分享了他对 Git 和分布式版本控制系统的见解，当时这还是一个全新的理念，这也是第一场关于 Git 的演讲。这次演讲处于我 2005 年底开始使用 Git 和我 2008 年中加入 GitHub 之间。我反复看了好几次，其他几百万人也是。谁不喜欢听 Linux 的创始人在谷歌的舞台上直言不讳地说“CVS 是有史以来最愚蠢的发明，所有不同意这个说法的人都是既丑陋又愚蠢的”呢？
除此之外，如果你将 Linux 与 Linus 本人混为一谈——大多数人确实如此——那么可以认为 Linux 间接促进了 Git 的普及（主要通过 Android）。这正是我难以衡量自己或 GitHub 所做的努力与那些默默无闻的幕后影响力相比有多大作用的地方——Android 在那时成为一个现象级的存在。即使我个人做了多年的 Git 演讲和企业培训，也很难说究竟有多大影响。
2008 年 9 月初，正值 Android 1.0 发布之际，Git 生态系统的早期杰出贡献者 Shawn Pearce 给我发了一封邮件，请求我协助培训谷歌的 Android 团队使用 Git。
很难确定 Android 在推动企业采用 Git 方面有多大影响，但可以肯定的是，它的影响绝非微不足道。虽然谷歌的 Android 团队是我以 GitHub 的名义进行的首次企业培训对象，但我最终也为摩托罗拉、高通、爱立信和博通等公司提供了 Git 培训。这些培训发生在我们组建一个团队全职从事这项工作之前。
Linus 用他的超级明星极客影响力推广了 Git，这是 Mercurial 从未享有的优势，而 Android 进一步推动了 Git 的普及，通过依赖 Linux 内核、将 Git 带入大型企业、纯粹基于实用性的考量，否则至少还要再等十年。
也许是因为 GitHub
也许最终决定 Git 超越 Mercurial 的因素是 GitHub。
GitHub 非常幸运地拥有一个令人难以置信的支持者社区，从一开始就热情地接纳了我们，即 Ruby 社区。在短短几个月内，Ruby 社区的每一个人都将自己的项目迁移到了 GitHub 上。Rails 当时非常火爆，比 PHP 更酷，JavaScript 框架还未兴起，Node.js 也尚未出现。因此，所有人都在关注 Ruby 社区里时髦人士在做什么，他们代表着软件开发世界的潮流。他们正在使用 GitHub。
不仅仅是我，甚至连 Linus 最近也提到，从他的角度来看，Ruby 社区出人意料地让 Git 一夜之间声名鹊起。虽然他没有直接提到 GitHub，但我认为任何人都无法否认，Ruby 社区之所以广泛采用 Git，在很大程度上是因为我们的贡献。
通过某种传递性推理逻辑和一些推测，我似乎可以声称“Linus 实际上认为 GitHub 是 Git 取得胜利的关键因素”。
当然，Ruby 社区采用 GitHub 并不是偶然的。
我还记得我们——Chris、Tom、PJ 和我——围坐在 Ruby 大会的桌子旁，向早期的 Ruby 社区成员展示 GitHub、推销 Git、做演讲等等。我们都在同一场会议上发表了演讲，并在旧金山的 Ruby 技术聚会后一起畅饮啤酒。这些人是 Rails、Heroku、Twitter、jQuery 等项目的先驱。
这并非我们在刻意“推销”GitHub，而是在分享我们所热衷的东西。这个社区有很高的信任度，GitHub 的创始人是其中不可或缺的一部分。我们都尝试使用彼此的产品，并相互提供支持。
我和 PJ 在 2009 年 3 月的苏格兰 Ruby 大会上，桌子旁坐满了了不起的早期 Ruby 开发者
Ruby 社区使用了 GitHub，这意味着每次会议上的演讲都会不可避免地提到一个 GitHub 插件。这就像是无处不在的免费广告。随着越来越多的项目转到 GitHub 或直接在 GitHub 上启动，即便是 Mercurial 的拥趸者也不得不开始使用 Git。久而久之，坚持使用 Mercurial 可能就变得不再有价值了，GitHub 在代码托管领域的主导地位在短短几年内就超越了 Mercurial。
在 Mercurial 领域，有 BitBucket 这样的平台，它是专门为 Mercurial 托管而构建的，并使用了 Django 框架。但我认为，GitHub 的起步太快，而且没有足够的差异化来吸引用户，所以 Python 社区并没有像 Ruby 社区那样积极地采用 Git。
早在 2008 年 12 月，GitHub 就已托管了大约 27000 个公共代码库，相比之下，BitBucket 仅有 1000 多个。迎头赶上变得愈发困难。
你可能会好奇我是如何记住这些数字的？那是因为我创建了一个叫作 whygitisbetterthanx.com 的网站。一位叫 Jesper 的人给我发了一封电子邮件，指出我网站上的一个观点是不准确的。我争论说 Git 有 GitHub 作为支持，而 Mercurial 和 Bazaar 却没有。我相当自信地争辩说，它们不在同一竞争水平上。
年轻的 Scott 有点刻薄。对不起，Jesper。
值得称赞的是，Jesper 从来没有因为我的反应而指责我。从我现在的角度来看，我当时确实有点刻薄。但事实证明，Jesper 其实是 BitBucket 的创始人。
大约一年后，我们在阿姆斯特丹见了面，一起品尝了一些上好的威士忌，自那以后，我们一直保持着友好的关系。
GitHub 联合创始人 PJ Hyett、我与 BitBucket 创始人 Jesper Noehr（穿着黑色衬衫）在阿姆斯特丹共享了竞争对手间的友好威士忌时光，大约是在 2009 年左右。永远记得要与你的竞争者保持友谊。
竞争市场崩塌
最后，无论是 GitHub 成就了 Git，还是 Git 帮助 GitHub 崛起，这场竞争很快便告一段落。
在 2006 年到 2007 年间，人们刚开始了解分布式版本控制系统，此时 Git 和 Mercurial 开始展开较量。
2008 年，GitHub 启动了。
2011 年，Google Code 和 BitBucket 相继引入了 Git 支持，我将这一年视为 Mercurial 的终结之年。Git 赢得了胜利，而 GitHub 如今也几乎已立于不败之地。
四年后的 2015 年，Google Code 彻底放弃了并关闭了代码托管服务。在他们发送的邮件中，他们基本上建议“直接迁移到 GitHub”。如果我没记错的话，他们甚至主动联系我们提供迁移支持。
为什么赢家不会是 Google Code？
当然，尽管 BitBucket 是在我们之后推出的，我们拥有先发优势，但也有一些托管服务是在我们之前就有的。那么，为什么它们没有赢呢？
2009 年初，Google Code 开始支持 Mercurial，而 Sourceforge 则开始支持 Git 和 Mercurial。既然这些行业巨头在我们启动几个月后就已经拥有庞大的用户基础和 DVCS 的全面支持，那么，为什么他们没有把我们这些后来者打得落花流水呢？
我们不仅规模小，而且缺乏资金支持。我记得 Chris 投入了一些资金来启动项目，但其他人手头拮据，没有筹集到任何外部资金。
当 Google Code 开始支持 Mercurial 时，我们四个人仍然只是在咖啡馆里工作，没有风险资本看上。2008 年 5 月，我们与 Engine Yard 的团队达成了协议，以便帮助我们支付托管费用，因为我们确实没有钱。
这个又小又缺乏资金的团队怎么可能在短短几年内就让 Google Code 认输呢？
说到融资的问题，有篇文章称“对联合创始人来说，风险资本不是一个选项”。我并不这么认为。
从创业之初，我们就与风险投资公司进行了接触。2008 年 7 月，PJ 给我发了一封邮件，表示他们希望我加入团队，我们应该全力以赴，辞去各自的工作，将这个项目从副业变成全职工作。他明确表示：“我们已经与一家我们非常看好的风险投资公司谈过，我们计划筹集一些资金来做一些事情。”这些事情包括租用办公室、招聘员工等。
融资一直是摆在桌面上的选项，我们在任何时候都可以这么做。我们考虑过，并在很多年里深思熟虑地拒绝了这个想法。我们并不是真的需要办公室，也不需要更多的人手。
不仅如此，四年后，当我们考虑从 Andreessen Horowitz 进行 1 亿美元 A 轮融资时，实际上几乎拒绝了这个提议。我记得非常清楚，2012 年 4 月，我们围坐在 Folsom 街的一家餐馆里，热烈地讨论我们是否应该接受这笔融资。
我们收到了来自 a16z、Benchmark、Sequoia 和 Bessemer（几乎是地球上最顶尖的风险投资公司）的报价，而我们四个人却坐在那里热烈地争论是否应该告诉他们“谢谢，但我们不需要”。这些可是其他科技企业家梦寐以求的报价。
关键是并不是我们无法筹集到资金，而是我们甚至不需要这些钱就能征服整个市场。
GitHub 是有品味的
Greg 的文章确实指出，其他公司更关注分销和收入现金流。我们则专注于开发者需求。但这并不是他们何时引入 Git 的问题，这并不是关键所在。他们缺乏品味，从未真正关心过开发者的工作流程。即使他们随时可以引入 Git，但我依然认为他们最终会输。
我认为，我们所做的一切事情的背后，更简单、更根本、更有趣的事情是我们为自己而构建。我们有品味，我们关心用户体验。
我们是开发者，我们构建我们想要的工具，以实现我们理想中的工作方式。我们是这个领域唯一一个由开发者为开发者而构建的平台，没有产品经理、会计或首席执行官试图以牺牲开发者体验为代价来提升收入。
最终我们赢了，因为开源社区开始聚焦在分布式版本控制上，而我们是托管领域唯一真正关心开发者工作方式的人。我们是唯一质疑现状、从第一性原则出发、试图全面改进它的人，而不是仅仅为了提升销售而添加更多功能的人。
为什么 GitHub 赢了
总结一下，我们赢了，因为我们有品味，我们生逢其时。
正当一个新的范式诞生之际，我们出现了，我们以一种无人能及或关注的以开发者体验为中心的方法，帮助人们接受这一新范式。
我觉得问题在于，下一个开发者工作流的重大变革会是怎样的，谁将拥有足够的品味并以同样的方式让它实现爆发式的增长？
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
