创始人深度复盘：GitHub为什么可以做成？

09-14 299阅读 0评论

本文作者是 GitHub 联合开创人 Scott Chacon。由于网络上有许多剖析 GitHub 成功的文章，他以为有些剖析不太对，所以写了这篇文章，从内部人的视角剖析了 GitHub 兴起与成功的原因。咱们一同来看看他是怎样说的。

假如你想立刻知道 GitHub 为何如此成功，以及你为何一向在运用它。我这儿有个精简版答案。

我将 GitHub 的成功归因于两个要害因素的完美结合。

GitHub 的推出机遇可谓完美
GitHub 很有档次

GitHub 的四位联合开创人都有过失利的阅历，无论是在 GitHub 之前仍是之后。Chris 和 PJ 在 GitHub 之前没能让 FamSpam 成功，而 Tom 和我在 GitHub 之后也没能让 Chatterbug 火起来。我以为这两个项目都很有品尝，并且是很棒的产品，但它们都没能像 GitHub 那样成功。这或许是推出的机遇不对，也或许是商场条件不成熟，或许还有其他原因。

GitHub 刚起步的时分，分布式开源版别操控东西开端变得既有用又安稳，逐步被人们选用，但在其时，简直没有人（更不必说商业范畴）真实认真地去保管这些东西。大公司看不上，小公司又由于不行专业够不着。

而那些后来注意到 Git 和 GitHub 兴起的竞赛对手（比方 Sourceforge、Google Code 等）却缺少那种共同的品尝。他们好像永久无法与一个以产品为中心的开源软件开发团队相抗衡。

咱们十分重视开发者的体会，并且具有满足的创造力，勇于打破常规，依照咱们自己的理念去构建产品。而其他人则只是在构建他们以为能够招引广告商或 CTO 的产品。

这便是 GitHub 能够胜出的原因。

原因现已说清楚了，假如你对详细细节感兴趣的话，请看下面内容。

一、环境

让咱们从开端一点一点地讲起。

我将站在 2005 年的一名软件开发人员的视点，来深入探讨 “GitHub 的诞生机遇适可而止” 这个主题。其时 Linus 提交了 Git 的第一个 commit，Olivia 提交了 Mercurial 的第一个 commit。

20 年前软件开发是什么样的？又是怎样的环境让 Git 赢得了人心，并促进 GitHub 诞生的呢？

Mac OS Tiger，2005 年发布。假如你运用的是 Mac，它看起来像这样。

假如你是 2005 年时的软件开发人员，你或许（期望）用的是 Subversion 这样的集中式版别操控体系。在 Git 呈现之前，我用过 RCS、CVS、Subversion，还有 Perforce。记住我待过的一家公司，乃至直接用 FTP 把 PHP 文件传到服务器上。那时分，咱们便是这么干的。

假如你其时在做商业专有软件开发，用 SVN 这样的集中式版别操控体系其实还算过得去。检出、修正、提交这些操作都很简略。虽然分支和兼并做得不怎样样，但许多时分咱们都能绕过去（说实话，我不确定自己是否真的在 Subversion 或 Perforce 里用过分支）。

说实话，现在人们诉苦 Git 的次数或许比当年诉苦 SVN 的还要多——究竟，SVN 的用户界面和操作逻辑比 Git 要简略直观。

Perforce 2005.1 可视化客户端。我很厌烦这个软件。

我觉得其时最大的问题并不在于那些封闭、团队之间相互信赖的专业开发环境。真实的应战在于那个不断强壮的开源国际。

你或许不知道，开源在那时分毫不起眼，尤其是跟今日比起来。现在的人们或许都不记住开源项目还没那么多的时分，“开源” 这个词直到 1998 年才被正式提出来。

为了让咱们有直观感触，2008 年，Dirk Riehle 宣布了一篇论文，剖析了全球开源项目的趋势。他估量那时分全球大约有 18 000 个活泼的开源项目。想想看，2005 年的时分，这个数字必定还要更小。

开源项目总数。摘自 2008 年 Amit Deshpande 和 Dirk Riehle 出书的《The Total Growth of Open Source》

比较一下，现在光是 GitHub 上就有逾越 2.8 亿个公共代码库。

那么，为什么开源的兴起会推进 Git 和 GitHub 的盛行呢？

首要是由于开源社区在快速扩张，而集中式版别操控体系在处理敞开奉献方面体现得很糟糕。简略来说，便是它们不拿手揭露共享项目，也不拿手轻松地把外部的奉献整合进来。这关于开源项目来说，是个大问题。

1. 2005年的开源奉献

真的有那么糟糕吗？

通常是这样的，你能够让你的 Subversion 服务器对未认证用户设置为只读，这通常是保管开源项目的方法（或许你会偶尔把一个压缩包放在某个当地）。

假如你想要奉献代码，底子流程是这样的：

拉取最新版别
进行修正
经过 GNU diff 东西生成补丁文件
将该补丁文件上传到项目运用的工单体系或邮件列表中

接着，维护者需求：

下载补丁文件
运用到项目上，看看是否运用成功/作业正常
然后供给反应、做出修正，或许提交更改

现在网络上仍然能够看到这种流程的留传痕迹。我曾在某个项目中运用 Trac 体系，你仍然能够找到他们的 “提交补丁” 攻略以及主张更改的示例。

这简直便是一场噩梦。

Rails 项目和我的那帮朋友们——也便是后来的 GitHub 联合开创人们——在 Err 公司用了一个叫做 Lighthouse 的工单体系，让人惊奇的是，它竟然还在运转。我前期的一个开源项目是一个指令行东西，叫做 git-lighthouse，它的功用是简化从工单中下载和运用补丁的进程。

下面是前期提交给 Rails 项目的补丁的 3 个不同版别的示例。

这个进程实在是太糟糕了，所以当有个东西能够简化这个进程时，咱们都刻不容缓地用上了。这个东西便是 GitHub。不过，在这之前，咱们得先有 Git。

2. Git的兴起

Git 的诞生其实有点戏剧性，Linux 内核大佬 Linus Torvalds 其时特别喜爱一个商业的版别操控体系，叫做 BitKeeper。这个体系本来是为了简化内核开发流程规划的。

假如 BitKeeper 是开源的，或许它的答应条款更友爱一些，或许就不会有 Git 或许 GitHub 了。

但作业就这么巧。有个 Linux 开发者违反了答应条款，反向工程破解了 BitKeeper 的协议。这搞得 BitKeeper 和 Linus 都很不爽，终究决议各奔前程。

所以，Linus 就结合了 BitKeeper 的一些好主意，自己搞了个东西，他觉得这个东西能解决问题。他还恶作剧地叫它 “来自阴间的信息办理器”，并将这个项目命名为 Git。

Git 很快就在 Linux 社区里火了起来，有几个人觉得这个项目不错，渐渐地，Git 就开展成了一个真实的版别操控体系。

其时 Git 之所以遭到欢迎，有这几个原因：

分支和兼并不再是噩梦，而是愿望
它速度飞快
权限办理变得十分简略

Git 刚出来那会儿，我做过一些现场演示，便是那种一边讲一边操作的。我会现场创立几个分支，提交一些更改，然后在这些分支之间切换，终究再兼并。整个进程趁热打铁，60 秒搞定。我还记住，其时真的有人看得呆若木鸡，乃至有人置疑我是不是作假了。

想想看，2006 年的时分，能这么快、这么轻松地切换和兼并代码，真的就像戏法相同。相比之下，在 Subversion 里做这些，简直便是一场噩梦。

不必跟中心服务器来回洽谈就能提交代码，这感觉就像是在开火箭，一切都快得飞起。

或许最要害的是，你能够轻松地 fork 代码库，这意味着你能够自己保管一个副本，具有写的权限，在自己的分支里提交更改，他人也能够轻松地把这些更改拉到他们的 fork 里。Linux 项目很早就开端这么做了——关于较大的更改，他们能够恳求 Linus 从他们保管的分支里拉取更改，而 Linus 做起来也是垂手可得。

实际上，假如你猎奇 “拉取恳求（Pull Request）” 这个词是怎样来的，答案就在这儿。Git 里有个 git request-pull 指令，它会帮你格式化一封邮件，发送到邮件列表，简化这个进程。当 GitHub 加上这个功用后，咱们决议就叫它 “拉取恳求”。

有些人觉得开发者喜爱 Git 是由于它分布式的特性，克隆时能拿到整个历史记录，这样你就能够在本地做各种操作等。但我不这么以为。分布式之所以酷，首要是由于操作快，你能够轻松地保管自己的完好可写 fork，权限办理变得超级简略。

的确，这种改变让奉献变得更简略了。不再是 “谁有权限推送”，而是 “谁有风趣的内容能够拉取”，这种改变直接推进了 GitHub 的诞生。

3. GitHub的兴起

上一年年末，我与我的 GitHub 合伙人 Tom 进行了详谈。咱们聊了许多，他叙述了他开端是怎样萌发开发 GitHub 的主意的。

其时他在 Powerset 作业，团队开端用 Git。可是，由于 Git 首要用 SSH 协议，给每个人设置 SSH 权限太费事了。大多数人觉得这事儿不值得操心。这个痛点让 Tom 有了创意：得让这事儿变得简略点。

Git 是挺棒的，但保管 Git 却很费事。这便是 Tom 开端开发 GitHub 的原因。

为什么要创立 GitHub？为了削减费事。

我翻了翻旧邮件，想看看我第一次传闻 Tom 的 “GitHub” 项目是啥时分。发现是 Chris 在 2007 年末回复我 Git 视频教程的邮件。

那时分，GitHub 仍是 Tom 和 Chris 的隐秘项目（还有 Chris…… 为啥 “h” 是小写？），我开端和 Chris、Tom 聊 Git/Ruby 库和网站的事，渐渐也就参加进来了，终究参加了公司。

这个项目有几件风趣的作业。

首要，他们把 GitHub 和其时仅有一个真实的公共 Git 保管站 repo.or.cz 作了比较。但 GitHub 做了个要害的立异，便是它以用户为中心，而不是以项目为中心。曾经在 Sourceforge 之类的当地保管项目，你得抢注姓名。而在 GitHub，你能够随便给项目起姓名，由于它是按用户命名空间区分的。

其次，他们重视的是 “拉取” 模型，而不是 “推送” 模型（这跟我之前说的权限问题有关）。

第三，“不丑” 也是一大卖点。GitHub 的规划很有品尝。

二、Git的成功

Git 一开端之所以受欢迎，是由于它的规划理念和功用都很强壮，而 GitHub 的创立则是为了让 Git 愈加易于运用。但问题是，为什么 Git 终究能在许多分布式版别操控体系（DVCS）中锋芒毕露呢？其时有许多相似的东西，比方 Mercurial，在许多方面和 Git 很像，乃至在某些方面做得更好。那么，为什么在这场 DVCS 的竞赛中，Git 笑到了终究？

我以为答案是 “PR”。

在 “为什么 Git 胜出” 这个问题上，有两个十分强壮的公关力气在起效果。首要是 Linux，能够说是 Linus 自己。其次是 GitHub，尤其是 Rails 社区。

1. 也许是Linus/Linux

Linux 项目挑选了 Git，并且仍是 Linus 主张的，这直接给了 Git 一个威望背书。

咱们都知道 Linux，也都知道 Linus。假如他能搞出一个简直人人都在用的优异操作体系（至少在服务器范畴是这样，并且每年都有人说下一年便是桌面 Linux 的年代），那他必定也能开宣布一个顶尖的版别操控体系。就算 Git 一开端用着有点难，那也只能阐明他比咱们聪明，咱们得多花点功夫学学，对吧？

2007 年的时分，有一个关于 Git 的在线讲座，其时 Linus 在 Google 园区里讲 Git 和 DVCS，那时分这仍是个全新的概念。

视频发布的时分，正好是我刚开端用 Git（2005 年末）和我参加 GitHub（2008 年中）之间的那段时刻。我看了好几遍，必定还有几百万人也看过。谁不想听 Linux 的大神在 Google 说 “CVS 是有史以来最傻的东西，不同意的人都是又丑又蠢” 呢？

这是一个很棒的公关活动。

并且，假如你把 Linux 和 Linus 同等起来（大多数人的确这么以为），那能够说，Linux 经过 Android 间接地也推进了 Git 的遍及。

在推进 Git 遍及这方面，有时分真的很难说，是我或许 GitHub 的尽力，仍是 Android 成为趋势背面的这种巨大而低沉的暗地推进力，二者哪个影响更大。究竟，我自己多年来也一向在做 Git 的演和解企业训练。

2008 年 9 月初，就在 Android 1.0 发布前夕（大约是这封邮件宣布两周后，也是在我做训练之前），Git 生态体系的前期英豪之一 Shawn Pearce 给我发了封邮件，约请我协助训练 Google Android 团队运用 Git。

虽然很难准确衡量 Android 在推进企业选用 Git 方面的效果，但它的影响必定不是零。Google/Android 团队是我以 GitHub 名义做的第一个企业训练目标，后来我还为摩托罗拉、高通、爱立信和博通等电信公司的工程团队做了 Git 训练。这仍是在咱们雇了全职团队专门来做这些训练之前的事。

Linus 用他那广泛的超级极客公关效应推进了 Git，这种影响力是 Mercurial 从未获得过的。而 Android 经过它对 Linux 内核的依靠，进一步共同地推进了 Git 的传达，让它进入了很多企业，这些企业本来或许至少在十年内都不会选用 Git。

2. 也许是GitHub

带着一点谦善和期望，我得说，GitHub 很或许是让 Git 终究打败 Mercurial 的要害。

GitHub 真的很走运，由于咱们有一个十分支撑咱们、也很前卫的社区——Ruby 社区。从一开端，Ruby 社区就全力支撑咱们。没几个月，Ruby 社区的每个人都把他们的项目搬到了 GitHub 上。那时分，Rails 是十分火的技能，比 PHP 更酷，JS 结构还没呈现，也没有 Node 这些技能。

所以，咱们都在重视 Ruby 社区那些潮流开发者的动态，由于他们是软件国际里最前沿的开发者，而他们都在用 GitHub。

不只是我这么看，Linus 最近也说，从他的视点来看，Ruby 社区让 Git 一夜之间意外地火了。他虽然没有直接说到 GitHub，但我觉得没人能否定，Ruby 社区没有选用 Git，很大程度上是由于 GitHub 的存在。

经过一些估测和推理，我敢斗胆地说，Linus 实际上以为 GitHub 是让 Git 制胜的原因。

当然，Ruby 社区的选用 GitHub 并非偶尔。

我记住咱们几个——Chris、Tom、PJ 和我——在 Ruby 会议上和 Ruby 社区的前期成员们坐在一同，向他们展现 GitHub，介绍 Git，做讲演。咱们一同讲演，之后还会在旧金山的 Ruby 聚会上一同喝啤酒。这些人是 Rails、Heroku、Twitter、jQuery 等项目的开创人。

咱们并不是在 “推销” GitHub，而是在共享咱们真实酷爱的东西。这个社区十分信赖互相，GitHub 的开创人也是这个社区的深度且真挚的成员，咱们都在测验互相的项目并互相支撑。

Ruby 社区运用 GitHub 意味着每场会议的讲演都会说到 GitHub。这种免费宣扬无处不在。跟着越来越多的项目搬迁到 GitHub 或许直接在 GitHub 上发动，即便是那些喜爱 Mercurial 的人也没有太多挑选，终究他们不得不转向 Git。一段时刻后，持续运用 Mercurial 就变得不太值得了。GitHub 在保管范畴的主导地位在短短几年内就逾越了 Mercurial。

在 Mercurial 那儿，有 BitBucket，它是专门为 Mercurial 保管规划的，是用 Django 结构写的。但我觉得咱们起步早，优势大，并且它们也没做出满足的差异化。Python 社区也没有像 Ruby 社区那样积极地选用它。

早在 2008 年 12 月，GitHub 就现已保管了大约 27 000 个公共库房，而 BitBucket 只要 1 000 多一点。要追上咱们的确挺难的。

你或许会猎奇我怎样记住这些数字。其实，我其时建了个网站叫 whygitisbetterthanx.com，有个叫 Jesper 的人给我发邮件，说我网站上有个过错——我其时的观点是，Git 有 GitHub，而 Mercurial 和 Bazaar 没有相似的保管渠道。我其时挺傲慢地回他说，它们底子不是一个量级的。

年青的 Scott 有点浮躁。对不住，Jesper。

很快乐 Jesper 并没有由于我的回应而气愤，现在想起来我那时分口气的确有点冲。但终究证明，Jesper 其实是 BitBucket 的开创人。这真的很为难。

大约一年后，咱们在阿姆斯特丹见了面，一同喝了几杯威士忌，从那以后咱们就一向保持着友爱的联系。

3. 竞赛对手的消失

终究，不管是 GitHub 帮了 Git 一把，仍是 Git 帮了 GitHub 一把，这场竞赛很快就有了成果。

2006年到2007 年的时分，咱们开端认识到分布式版别操控体系的优点，Git 和 Mercurial 也开端了正面交锋。

2008 年，GitHub 正式上台。

到了 2011 年，Google Code 和 BitBucket 都开端支撑 Git，我觉得这差不多便是给 Mercurial 敲响了丧钟。Git 赢得了这场战役，GitHub 也变得简直无人能敌。

只是 4 年后，2015 年，Google Code 完全退出了历史舞台，封闭了服务。他们乃至在邮件里主张咱们直接转移到 GitHub。假如我没记错的话，他们还联系了咱们，寻求协助进行搬迁服务。

三、那么，为什么不是 Google Code 胜出呢？

这是个好问题。虽然 BitBucket 是在咱们之后发动的，咱们有一些先发优势。不过，在咱们之前也有其他保管网站。那么，为什么它们没有胜出呢？

2009 年头，Google Code 添加了 Mercurial 支撑，Sourceforge 也添加了 Git 和 Mercurial 支撑。因而，假如这些职业巨子具有用户群优势，并在咱们上线几个月后就支撑了 DVCS，为什么他们没有打败咱们这些小公司？