GitHub 如何成为代码托管的领头羊，超越 SourceForge [译]

自高中起，我便开始编程。我还隐约记得，曾与一位朋友共同利用 TortoiseSVN 分享代码，开发了一款安卓游戏。大学期间，我学会了从 GitHub 克隆仓库以获取计算机科学作业。之后，在实习期间，我开始使用 GitHub 审核和合并合并请求（PR）。像我这样在过去十年内步入职业生涯的大多数开发者，可能都有着类似的经历——不论是参与开源项目还是公司私有团队，GitHub 都成了源代码和代码更改的代名词。

我们往往认为 GitHub 的无处不在是理所当然的——但它是如何做到的呢？

我询问了我的团队成员 David，一个编程时间比我长十年的老手，他如何认识到 GitHub 的。他经历了从 SVN 到 GitHub 的专业转变。在 2000 年代，他回忆说在编程工作中使用 SVN，从 SourceForge 下载软件，但他认为其界面功能单一且设计粗糙。随着时间的推移，他越来越频繁地访问 GitHub，以寻找文档和下载如 Rails 这样的开源工具。这促使他深入了解 Git，并最终在工作中使用 git-to-svn translator。然而，直到 2010 年前后，许多公司仍然在使用 SVN 托管代码，直到几年后，大多数私人组织才全面过渡到 Git。

David 的经历让我对 GitHub 的崛起充满了好奇。在 GitHub 出现之前，市场上有什么？GitHub 又是如何填补了这个空白的？

在 GitHub 出现之前

2004 年，也就是 GitHub 成立的四年前，Linus 发明了 Git。尽管很多人还在使用 SVN，但作为一种分布式版本控制系统的 Git，其受欢迎程度正在飞速上升。Git 的出现，与以往如 CVS 和 SVN 等工具相比，提供了显著的优势。Git 允许用户在自己的电脑上存储完整的源代码副本，无需与任何中央服务器进行通信。这意味着用户可以随时更新代码（即使在无网络的情况下！），并且无需经过中心管理的同意或支付托管费用，就可以相互分享代码副本。此外，与 SVN 中需要复制整个仓库以创建分支的做法不同，Git 中创建分支既快速又低成本。

可以想象，这样的改进促进了开源社区中创意发展的激增。Git 被设计来支持分布式的、民主化的开发方式，其传播速度极快。然而，尽管存在这些优点，Git 在企业代码库的推广却相对缓慢，这些企业仍然依赖于私有的、中心管理的 SVN 服务器及其传统工作流。

时间快进到 2008 年。开源项目如 Rails 开始跟随 Linux 的脚步采用 Git。而私人机构仍旧依赖 SVN 和 Perforce 服务器来中心化地管理源代码。开源软件的主要分发渠道是 SourceForge，随后是 Google Code，或者较为少见的个人托管服务器。

尽管 SourceForge 一度占据主导地位，但它存在许多不足之处。例如，直到 2009 年，也就是 GitHub 成立一年多并且用户数量达到 100k 之后，SourceForge 才开始支持 Git。但两者之间的区别远不止技术层面。如今，当我们谈论在线代码托管时，我们指的是一个可以方便地浏览代码、问题和贡献者的网站。而 SourceForge 提供的体验远远不是这样。与其说它和 Google Code 等替代品着重于代码协作，不如说它们更侧重于向最终用户分发软件。这些平台通过汇集开源项目的分发解决了一部分问题，但在评论、代码浏览、变更审查以及其他现代化的基础功能方面几乎没有提供任何支持。

情形愈发严峻。在 SourceForge 上搭建和维护代码仓库简直是一场折磨。首当其冲的问题是，创建新的仓库不仅需要提交申请，还必须经过人工审核。而且，该平台从不支持私有仓库，这就意味着它对于需要闭源托管的项目毫无用处。项目上的评论和问题反馈环节设计得既不直观又不友好，而且对代码进行分叉（forking）几乎是闻所未闻的做法。如果你打算为某个项目做出贡献，最通行的方法是创建一个补丁，接着通过项目的邮件列表发送——这种方式与分叉项目然后提交拉取请求（pull request）相去甚远。20 年后回顾 SourceForge，令人惊讶的是，它和如今的 Apple App Store 有着惊人的相似之处。从这个视角出发，GitHub 所能填补的市场空白愈发明显。

早期的竞争对手：SourceForge 与 Google Code

让我们回看 2008 年 SourceForge 的首页，能发现什么呢？它自豪地声明自己是互联网上最大的开源专注网站，页面上醒目地展示了下载量和重点项目，新软件的版本更新，甚至在页面的右侧还有广告推送。但你会发现，页面上并未提及 Git，对用户个人资料的关注也不多，更不用说提供私有仓库的服务了。其主要关注点在于软件的分发，而不是促进开发者之间的协作。

以 SourceForge 上的一个仓库为例，其页面设计的核心是一个明显的下载按钮，与之对比的是，这里并没有像现代代码托管平台那样，设有克隆仓库的按钮。

code.google.com 在逐步改善方面稍胜一筹于 SourceForge。这个平台致力于简化代码和文档的免费托管流程，并充分利用了 Google 在搜索方面的强大能力来帮助用户发现资源，同时为那些希望学习的开发者提供了详尽的文档。然而，它在社交和协作功能方面的缺失，后来证明这对于开源开发者来说是至关重要的。另外，虽然起初仅支持 SVN，直至 2011 年 Google Code 才添加了 Git 托管的功能，这一进步被一篇标题充满机智的 Wired 文章 所报道。

GitHub 的诞生

在 2008 年的一个晚上，Tom Preston-Werner 和 Chris Wanstrath 在旧金山的一家体育酒吧结束了 Ruby on Rails 的聚会后，坐下来喝了一杯。那时，Rails 社区越来越倾向于使用 Git，然而，并没有像 SourceForge 那样的平台来托管 Git 仓库。同时，社交网络正蓬勃发展，但却缺少一个专门为像他们这样的开源项目开发者设计的社交网站。Git 使协作软件开发变得前所未有地简单，虽然有像 SourceForge 这样的网站帮助发布版本化的软件，但却没有一个真正适合协作的在线家园。如果有一个平台能让人们托管源代码，讨论问题，并邀请维护者合并分支改动，同时还提供了类似 Facebook 的个人资料页面和评论功能，那会怎样呢？

这对未来的 GitHub 联合创始人开始将这个想法变为周末的项目实践。他们利用周末的时间，用 Rails 开发了 GitHub 的基础功能，直到它足够成熟，能够被 Chris 在他的日常工作中使用。他们每天亲自使用这个平台，逐步发现并解决了各种问题和功能缺失。

“GitHub 这家公司似乎是从一个边项目逐渐成长起来的，我们当时并没有什么宏伟的愿景或梦想。我们只是想参与一些我们认为很酷的项目。”

—— Chris Wanstrath

Ruby on Rails 的创始人也是 GitHub 的早期拥趸，他对于提升该平台初期的知名度起到了举足轻重的作用。

回顾 2008 年的 GitHub

在 2008 年，GitHub 的界面是怎样的？下面的图片带你一探究竟。感受一下那时的 GitHub，你会发现与今日相比，它的样子简直判若两人。

GitHub 最初的标志中包含了一个明确的声明：“社交化的代码托管”(Social code hosting)，而它们最吸引人的品牌承诺则是：“Git 仓库托管，再也不是令人头疼的问题。”(Git repository hosting, no longer a pain in the ass.) 这句话清楚地表明了 GitHub 创立之初的两大核心优势：它不仅是一个能够让开发者在社交网络环境中相互协作的平台，还提供了一个在线上托管 Git 仓库的简便方法。这种独特的结合让 GitHub 在当时的市场上独树一帜，没有任何其他网站能在这两个领域同时提供竞争性的服务。

项目与开发者动态追踪： 保持对您钟爱的项目及其开发团队成员的最新动态的了解。

源代码浏览器： 无论是在哪个版本、分支或标签，您都能轻松查看您的代码。

**公开的开发者档案：**探索其他开发者的项目进展以及他们提交的次数。

“对于任何平台而言，杀手级应用是决定成败的关键。对 GitHub 来说，我认为它刚刚展示了它的价值。” —David Heinemeier Hansson

“GitHub 真正做到了将社交元素融入其中的不凡之处。通过 Chris 和 Tom 的展示，我们可以直观地看到 git 开发应该是怎样的。我记得当我开始从外部 git 仓库合并提交时，有了许多‘啊哈’的时刻。” —Rick Olson

“你可能已经不是第一次听说这个了，但我还是要说，GitHub 实在是太棒了。我之前从没想过需要把我的代码托管到这样的服务上，但现在，我找到了理由。” —Josh Susser

GitHub 异军突起

经过内部试用 MVP 后，GitHub 的创始人向朋友们推出了一个托管公开仓库的免费测试版。

GitHub 在开源社区中的增长如同燎原之火，充分证明了它与市场的完美契合。Rails 项目很快采纳了 GitHub，并且要求使用者必须通过 GitHub 来进行 Ruby on Rails 的开发（这也是许多人，比如我的团队同事 David，首次接触到 GitHub 和 Git 的方式）。

• 创立的第一年内，GitHub 的公开仓库数量增长到了 46,000 个。

• 第二年，仓库数量增至 90,000 个，用户数达到了 100,000。

• 第三年，仓库数量飙升至 100 万个。到了 2011 年，GitHub 在规模上已超越了 SourceForge 和 Google Code。

尽管初期发展迅猛，GitHub 的三位创始人依旧坚持低成本运作和自我资金支持的方式。他们迅速采取行动以创造收入，与 SourceForge 依赖广告不同，也未像 Perforce 那样专注于企业销售，GitHub 的创始人很快推出了不同等级的订阅服务，专门用于托管私有仓库。这种模式简单明了、易于自助操作，并且在当时的托管产品和社交网站中颇具创新性。Google Code 和 SourceForge 不支持 Git 仓库托管，更不用说私有代码托管了。在 GitHub 之外，想要私人仓库托管，唯一的选择只能是自行管理服务器。

除了通过订阅迅速获得收入外，GitHub 的联合创始人们还寻找了其他的盈利和节省成本的方法。他们探索了包括单次广告位、在线商品店、Git 培训服务以及在线招聘版块在内的多种收入来源。为了将业务成本降至最低，GitHub 选择与 Engine Yard 合作，并后续与 Rackspace 合作，通过提供页脚广告换取免费的托管服务。

在 2009 年，GitHub 推出了一个允许大型企业自行搭建和运行 GitHub 平台的版本，这标志着企业不必再依赖 SVN 服务器或类似 Perforce 的产品，而是可以利用他们新掌握的 Git 工具来进行开放源代码和私有源代码的开发。2010 年，GitHub 为组织和团队推出了专属计划，深入私有代码托管和协作变更的市场。到了 2011 年，他们把 Github Fi 升级为正式的企业服务器产品。

“我们推出 GitHub Enterprise 产品，目的是让更多人使用 GitHub。无论您是处于防火墙之内还是能够自由访问互联网，我们希望 GitHub 都能成为您的得力助手。”

-Chris Wanstrath

通过革新传统的代码托管商业模式，GitHub 获得了足够的资金扩展团队并进一步提升产品体验，超越了以往任何产品的成就。但这种深入的收入追求和独立自主的增长策略并非仅是选择而已——对于创始人来说，寻求风险投资并不在选项之列。直到 2010 年为止，制作开发者工具的公司很难吸引到显著的投资。

"即便是在工具公司通过如 2013 年 Facebook 收购 Parse 这样的交易看到了退出机会，这家移动应用工具的开发者被估价 8000 万美元，这个数字也被认为偏低。对于一些人来说，开发者工具始终是风险投资的无人区。"

-Forbes

得益于 Heroku、Atlassian、Stripe、Twilio 和 Sendgrid 的投资动力，市场终于开始打开。六年后，GitHub 才得到了 Andreessen Horowitz 的大胆投资——1 亿美元，这被标榜为史上最大的 A 轮融资。

哪些公司没有使用 GitHub？

Google 从来没有在其内部工作中采用 GitHub。在 2000 年代，他们一直在使用 Perforce，并且后来开发了一个自定义的版本控制系统，名为 Piper。Google 不仅拥有先进的版本控制工具，据悉，他们还是网络代码审查的发明者。他们在 2004 年推出的早期代码审查平台受到了 Gmail 的启发，为公司软件开发流程设定了标杆。对于 Git 和 GitHub，Google 并没有迫切的需求。

Facebook 同样没有选择 GitHub 作为其内部开发平台。约在 2010 年，Facebook 的 Evan Pricely 开发了 Phabricator — 这是在 GitHub 正式推出企业自我托管服务前的一年。即便 GitHub 的产品当时已经上市，Facebook 也可能仍旧会选择开发自己的工具，这样可以更好地与公司内部的定制解决方案进行整合，并应对连原始 Git 也难以处理的大型代码库。而且，Facebook 后来将其代码管理工具从 Git 更换为了 Mercurial，而 GitHub 对此并没有提供正式的支持。

有些独角兽企业，比如 Airbnb，很早就开始使用 GitHub 了。而 Uber 和 Pinterest 这样的知名公司则选择了自托管并分支 Phabricator。我认为，选择 Phabricator 的公司可能是因为它既是最佳的可自托管、开源的源代码管理服务，又因为这些公司中有许多前 Facebook 员工，他们希望继续使用他们熟悉的工具链。

GitLab 从 2011 年起，便以与 GitHub 不同的策略立足于市场，致力于打造一个全面的开发 - 运维（dev-ops）平台，区别于 GitHub 的“社交编程”模式。GitLab 顺应 DevOps 快速发展的趋势，并通过强化持续集成/持续部署（CI/CD）的功能，在包括 Nvidia 在内的众多科技巨头中赢得了市场份额。

在 2024 年，我在 Graphite 工作期间，与上千个高科技工程团队交流的经验告诉我，几乎所有公司都在使用 GitHub，这已是不争的事实。尽管 StackOverflow 在 2022 年的调查显示，GitHub 在专业市场的份额仅是 GitLab 的两倍，但根据我的观察，大约 95% 的现代科技公司选择使用 GitHub。其中，只有极少数公司选择自托管 GitHub 企业版。其他的则是使用 GitLab、Phabricator、Gerrit 或是开发自己的内部代码托管平台。

GitHub 和代码托管未来的展望

Git 的原创开发者 Linus Torvalds 对 GitHub 的托管功能给予了高度评价，他说：“GitHub 提供的托管服务非常出色，他们在这方面的表现值得大大地赞赏。但是，他同时对 GitHub 的合并功能表达了批评，认为“尽管 Git 自带了优秀的拉取请求生成工具，GitHub 却选择了一个自己的、远不如原版的替代品。因此，对于这类操作，我觉得 GitHub 根本派不上用场。虽然它的托管功能不错，但拉取请求和在线代码编辑简直是糟糕透顶。”
-Wired

那么，未来的代码托管将走向何方？在 Clay Christensen 的经典之作 The Innovator’s Dilemma 中，他指出早期的创新产品往往是集成化的解决方案。我认为，GitHub 和 GitLab 就是这种一站式服务的典范，它们为团队提供了一个便捷的源代码管理平台。

Christensen 提到，随着市场的发展，解决方案会趋向于专业化和模块化。在“社交编码”领域，这一变化已经初现端倪。例如，Jira 和 Linear 提供了模块化的问题跟踪服务，Jenkins 和 Buildkite 则提供模块化的持续集成（CI）服务。GitHub 虽然是最初的 Git 仓库托管服务提供者，但随后 BitBucket 和 AWS Code Commit 等也提供了同类服务。现在，GitHub 提供了集成的合并队列功能，但 Mergify、Aviator、Trunk 和 Graphite 等更为专业化的服务也已出现。

GitHub 因其强大的网络效应和适合开源开发的产品特性（如代码分叉、论坛式评论和内容管理）而在开源代码托管领域保持领先。而封闭源代码仓库最初之所以选择 GitHub，是因为其在 Git 托管方面的专长——但这一能力现在已是众多提供商的标配。在私有公司，GitHub 的社交特性几乎不被采用，因为讨论和沟通更多地通过 Slack、Notion、Linear 和 Zoom 等工具进行。

我相信，未来将见证开源和封闭源开发工具的分化。开源合作需要的是讨论、用户个人资料、内容管理、代码分叉和项目发现等功能。而封闭源合作则更注重代码审查的效率，需要的是基于主干的工作流、合并队列、紧急处理机制以及持续集成/持续部署（CI/CD）的协调。虽然这两种需求有所交集，但我相信，随着时间推移，不同的使用场景将会促使解决方案向更加专业化的方向发展。

我们已经目睹了 Facebook 和 Google 推出的特色解决方案。他们通过超越 GitHub 开源平台的限制，单独发展他们的源代码管理系统，打造出了如 Google 的 PR 收件箱和 Facebook 的层叠修改这样的创新功能。

我期望模块化能进一步发展，让每个工程师都能自由选择源代码的托管方式，而这种选择不受他们使用的编码工具的影响。我们在开发的其他方面已经看到了类似的自由度，例如，开发者可以根据个人偏好选择集成开发环境（IDE）或云服务提供商。**GitHub 凭借其在代码托管和社交编码方面的深度专业化，公平地建立起了其领导地位 —— 然而，这不代表故事就此结束。**未来有一天，我希望开发者在选择托管平台时，不是只有一个选项，而是有五个竞争者可供选择。

💡 免责声明：我入行还不够久，GitHub 成立之前我还没开始专业编程。这篇文章里的很多观点是我通过网络资源、访谈和个人在这个行业的经历拼凑而成的，是我对整个行业发展态势的一个初步理解和展望。

完整时间线

1. 1999 年：SourceForge 正式上线，标志着第一个免费的开源项目托管平台的诞生。

2. 2004 年之前：项目版本控制广泛使用 CVS 和 SVN；在这一时期，SourceForge 在开源项目托管领域遥遥领先。

3. 2004 年：Linus Torvalds 创造了 Git（一个分布式版本控制系统），彻底改变了版本管理的方式。

4. 2006 年：Google Code 推出，最初只支持 SVN 版本控制系统。

5. 2008 年：GitHub成立，专注于提供 Git 仓库托管服务，并以社交编程为特色。

6. 2009 年：SourceForge 开始支持 Git；同时，GitHub 推出了自托管版本，为之后的 GitHub 企业版埋下伏笔。

7. 2010 年：Facebook 开发了 Phabricator，这是一套面向代码审查和软件开发的网络工具。

8. 2011 年：GitLab成立，其强调提供一站式的 DevOps 平台；Google Code 也开始支持 Git。

9. 2012 年：GitHub 推出企业版，满足大型企业对于私有托管的需求。

10. 2016 年：随着 Google Code 的关闭，GitHub 在代码托管领域的领导地位愈加明显。

11. 2018 年：GitHub 引入了 GitHub Actions，进一步自动化了软件开发流程中的工作流程。

12. 2021 年：由于 Phabricator 停止了积极维护，更多的用户开始转向使用 GitHub。