自高中起，我便开始编程。我还隐约记得，曾与一位朋友共同利用 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 成立之前我还没开始专业编程。这篇文章里的很多观点是我通过网络资源、访谈和个人在这个行业的经历拼凑而成的，是我对整个行业发展态势的一个初步理解和展望。
完整时间线
-
1999 年：SourceForge 正式上线，标志着第一个免费的开源项目托管平台的诞生。
-
2004 年之前：项目版本控制广泛使用 CVS 和 SVN；在这一时期，SourceForge 在开源项目托管领域遥遥领先。
-
2004 年：Linus Torvalds 创造了 Git（一个分布式版本控制系统），彻底改变了版本管理的方式。
-
2006 年：Google Code 推出，最初只支持 SVN 版本控制系统。
-
2008 年：GitHub成立，专注于提供 Git 仓库托管服务，并以社交编程为特色。
-
2009 年：SourceForge 开始支持 Git；同时，GitHub 推出了自托管版本，为之后的 GitHub 企业版埋下伏笔。
-
2010 年：Facebook 开发了 Phabricator，这是一套面向代码审查和软件开发的网络工具。
-
2011 年：GitLab成立，其强调提供一站式的 DevOps 平台；Google Code 也开始支持 Git。
-
2012 年：GitHub 推出企业版，满足大型企业对于私有托管的需求。
-
2016 年：随着 Google Code 的关闭，GitHub 在代码托管领域的领导地位愈加明显。
-
2018 年：GitHub 引入了 GitHub Actions，进一步自动化了软件开发流程中的工作流程。
-
2021 年：由于 Phabricator 停止了积极维护，更多的用户开始转向使用 GitHub。
