GitHub 正面临重大危机！
MMaximilian Schwarzmüller
Computing/SoftwareBusiness NewsManagementInternet Technology
Transcript
00:00:00GitHub 正处于一个非常危急、非常糟糕的境地。
00:00:04那里存在许许多多的问题，其中很多都与 AI 相关，
00:00:08但原因可能并非如你所想，
00:00:10不过我稍后会再谈到这一点。
00:00:11当然，这非常重要。
00:00:13这很重要，因为 GitHub 是现代开发工作的
00:00:16核心支柱。
00:00:17无论你是在进行开源开发，
00:00:20还是在维护一些开源项目，
00:00:22或者只是在开发自己的项目，
00:00:24你的个人项目、你的业余项目，
00:00:26如果你在经营一家小企业、一家小公司，
00:00:29又或者你是在一家规模更大的公司，
00:00:32它被广泛用于各种用途，作为代码存档、
00:00:35用于 CI/CD 工作流、用于协作、
00:00:38通过 Issue 共同参与项目、
00:00:42通过 Pull Request 以及许多其他功能和使用场景。
00:00:47所以这很重要，但正如刚才提到的，
00:00:49目前存在非常多的问题。
00:00:51在探究原因以及这对未来意味着什么之前，
00:00:53让我们先看看目前出了什么问题。
00:00:54...
00:00:57让我们从一个大问题开始。
00:00:59昨天报告了一个重大、巨型、
00:01:02简直令人难以置信的安全漏洞，
00:01:07就在我录制这段视频的时候。
00:01:09github.com 上出现了一个远程代码执行漏洞。
00:01:12我的意思是，读到这条消息简直疯了。
00:01:16它是由一家名为 Viz 的安全公司发现的，
00:01:19而且并未被利用过。
00:01:21所以它是被发现、被报告并被修复了。
00:01:25没有造成任何损害。
00:01:28根据 GitHub 的说法，
00:01:31他们也针对这份报告发表了回复。
00:01:33现在，我不会深入探讨
00:01:36该漏洞具体是如何运作的。
00:01:39不过我会把文章链接放在下面。
00:01:42但最终，这一切都是通过 git push 实现的。
00:01:44所以不涉及网络钓鱼，
00:01:46没有员工账号被盗，
00:01:49也没有供应链攻击。
00:01:51我们在过去几周见过很多此类事件，
00:01:54但不，这次完全没有涉及这些。
00:01:56相反，它只是通过 git push，
00:01:58具体来说是标准的 push option 功能，
00:02:03你可以将其添加到 git push 命令中
00:02:05以便为该推送命令附加额外的选项。
00:02:10通过这个选项功能以及该漏洞，
00:02:13结合 GitHub 处理推送的方式，
00:02:17安全研究人员能够附加代码，
00:02:22并让其直接在 GitHub 服务器上执行。
00:02:27具体细节同样在那份报告中，
00:02:31但归根结底，他们利用了这样一个事实：
00:02:34你可以向 xstat 请求头添加额外的元数据，
00:02:39而该请求头会借由 push options 标志进行填充。
00:02:44那些元数据，也就是你可以随推送请求
00:02:49通过该请求头传递的信息，
00:02:52最终并没有被 GitHub 进行清理过滤。
00:02:54他们最终只是对推送请求、
00:02:58推送命令进行了身份验证。
00:02:59他们检查了你是否有权向
00:03:01你尝试推送的代码仓库进行推送，
00:03:03但随后他们直接获取了那些选项数据，
00:03:07并在未清理数据的情况下构建了 xstat 请求头。
00:03:12这使得安全研究人员
00:03:15能够执行一些命令，而这些命令随后
00:03:18不仅限于他们所推送的仓库，
00:03:21而是在 GitHub 服务器上自由运行，
00:03:24并且能够访问其他仓库，
00:03:27包括私有仓库。
00:03:29现在，再强调一次，这个漏洞已被报告并修复，
00:03:33它已经不存在了，
00:03:35但显然这是一个巨大的漏洞。
00:03:39我的意思是，出现一个允许在
00:03:43github.com 上进行远程代码执行的漏洞是件非常严重的事。
00:03:45这真的非常严重。
00:03:47所以，是的，这是一个大问题，
00:03:48但当然，这并不是唯一的问题。
00:03:51就在几天前的 4 月 23 日，
00:03:56发生了一起与 GitHub 合并队列（merge queues）相关的重大事故。
00:04:01万一你不知道，GitHub 合并队列
00:04:04是 GitHub 的一项功能，旨在用于那些
00:04:07活动频繁、开发活跃、
00:04:11有大量 Pull Request 涌入的仓库。
00:04:13为了确保你不需要在发送新请求之前
00:04:16先合并每一个 Pull Request，
00:04:19因为你肯定希望针对仓库的最新状态
00:04:21（例如 main 分支）发起 Pull Request，
00:04:24...
00:04:26为了确保你不需要在开启新请求之前
00:04:28逐一合并之前的每一个 Pull Request。
00:04:30最终，这个合并队列功能应运而生，
00:04:34它的简单目标就是有效地
00:04:38预先创建一个中间合并状态，
00:04:42为每一个 Pull Request 创建一个
00:04:46你正尝试合并到的分支或仓库的新状态。
00:04:49如果有一个新的 Pull Request 被添加到
00:04:51Pull Request 链中，
00:04:53它也会与排在它之前的 Pull Request
00:04:57一起预先合并到主分支中，
00:04:58这样开启新的 Pull Request 时，
00:05:01就好像之前的请求已经合并了一样。
00:05:05这单纯只是为了让团队工作得更快，
00:05:08因为你可以不断开启更多的 Pull Request，
00:05:10而无需等待前面的请求先完成合并。
00:05:13当然，它们最终都会被合并，
00:05:15但这能让你持续工作，
00:05:17这对大团队来说显然非常重要。
00:05:19现在，与该功能相关的另一个重点
00:05:22当然是它必须能正确运作。
00:05:24而在 4 月 23 日发生的事情是，
00:05:28GitHub 在处理这些不同的 Pull Request 时
00:05:32出现了一个内部逻辑错误，
00:05:37导致它最终产生的合并
00:05:41会丢失一些信息，从而导致
00:05:45出现无效的 commit，并抹除掉
00:05:49部分 Git 历史记录。
00:05:50虽然数据实际上并没有丢失，
00:05:53但该功能运作不正常
00:05:55并产生了错误的 commit。
00:05:57这就是事情的简短版本和要点。
00:06:00当然，这也是完全不可接受的，
00:06:03如果你是一家大公司，或任何依赖该功能的
00:06:06公司，突然间你的项目陷入了
00:06:09崩溃状态，而你却没有任何明确的解释，
00:06:13这当然是不可接受的。
00:06:16而且你的第一反应通常不会是
00:06:19合并队列功能里存在某种内部 Bug。
00:06:23你大概率会觉得是自己哪里做错了。
00:06:26所以你会花大量时间寻找错误，
00:06:28直到你发现：哦不，是 GitHub 的问题。
00:06:30当然，除此之外，还有
00:06:33GitHub 持续存在的在线/离线稳定性问题。
00:06:38现在的官方状态页看起来很糟，
00:06:42或者可能还行，但至少对于大多数系统来说，
00:06:46我们在这里也没有达到 99.9% 的在线率。
00:06:49他们确实分别为不同系统报告了在线率。
00:06:53但如果我们看看“缺失的 GitHub 状态页”
00:06:55（missing GitHub status page），情况就大不相同了，
00:06:57它以另一种方式追踪在线率，
00:07:00并将每一个微小的事故都视为一个问题，
00:07:04归根结底都算作停机时间。
00:07:05对于 GitHub 这样关键的系统来说，
00:07:10这里的在线率简直糟糕透顶，当然是完全不可接受的。
00:07:14所以在过去的几个月里，我们一直面临在线率问题，
00:07:18甚至从去年就已经开始了。
00:07:20此外，各处还存在一些较小的 Bug，
00:07:23只是不像这个 Bug 这么大，或者不像
00:07:26那个安全漏洞那么重要。
00:07:28但没错，问题非常多，
00:07:31不幸的是，GitHub 在此时已然成为一个
00:07:36不可靠的平台，
00:07:38考虑到它在现代开发中的角色和重要性，
00:07:43正如我最初所说，这简直是一场灾难，
00:07:47无论你从事哪种开发工作。
00:07:50另一个问题是，来自 GitHub 官方的沟通
00:07:54一直，怎么说呢，并不多。
00:07:59一直以来沟通寥寥，
00:08:01但在 4 月 28 日，也就是那个安全漏洞出现前，
00:08:06他们分享了一篇博客文章，
00:08:10在那篇博文中，他们稍微解释了正在发生的事，
00:08:14以及这些问题源自何处，
00:08:16并表示他们理解之前的沟通策略
00:08:19并不理想，情况将会好转。
00:08:23接下来是下一部分。
00:08:25这些问题到底是从哪儿来的？
00:08:28这里的官方声明将 AI 列为原因，
00:08:32但并非指微软的 GitHub 工程师们
00:08:36在使用 AI 编写并发布劣质软件、
00:08:40向 GitHub 发布有缺陷的更新。
00:08:43那也许正在发生，但我们没有证据。
00:08:47相反，这里引用的主要原因是，
00:08:51由于 AI 的出现，衍生出了如此之多的项目，
00:08:57生成了如此之多的代码，
00:09:00最终，所有这些项目和代码
00:09:03都被推送到了 GitHub。
00:09:04他们分享了一些……嗯，怎么说呢，并不是特别有用，
00:09:09但他们确实分享了一些图表。
00:09:12这些图表没啥大用，因为没有 Y 轴。
00:09:14我们看不到绝对数值，
00:09:17但我们当然可以看到这里的比例关系。
00:09:20我们显然可以看到，在 2025 年，
00:09:23合并的 Pull Request 数量急剧增加，
00:09:28推送的 commit 数量，当然还有新开设的仓库数量也是如此。
00:09:32这些全都是我们现在用 AI 创建
00:09:34但却没完成的业余项目。
00:09:36然后在 2026 年，显而易见，对于所有这些指标，
00:09:41图表曲线简直是直冲云霄。
00:09:46所以，是的，这无疑是一个非常明显的趋势。
00:09:49而这种流量，这种流量的激增，
00:09:54当然会让任何系统承受巨大的压力。
00:09:58这对 GitHub 来说尤其成问题，
00:10:01因为他们正处于迁移过程中，
00:10:05正试图从单体架构以及他们自己的专用
00:10:09数据中心或系统迁移到 Azure 云端，
00:10:13并转向一个更加分散的系统，你可以说是
00:10:17微服务系统，而不是之前的单体结构。
00:10:21在进入 2026 年之前，这一直是一个持续的过程。
00:10:26但当然，这意味着现在的迁移进程
00:10:31正好撞上了需求爆发的峰值，
00:10:34这意味着即使在迁移过程中，
00:10:36你也必须在继续迁移的同时
00:10:39稳定现有的系统，
00:10:40从而希望这能有助于应对未来
00:10:44流量的增长。
00:10:46当然，这只是希望，并不能保证。
00:10:50但这确实是 GitHub 必须面对的问题。
00:10:52他们在这里提到，他们从 2025 年 10 月开始
00:10:56执行一项将 GitHub 容量提升 10 倍的计划。
00:11:01所以你可以说，大约在这个时候他们发现，
00:11:04嗯，需求都在上涨。
00:11:06我是说，他们在那之前就已经能察觉到了，
00:11:09但就在这时，他们决定需要将容量扩大 10 倍。
00:11:13然后到了 2026 年 2 月，他们发现，
00:11:16好吧，我们需要的是 30 倍，而不是 10 倍，因为，
00:11:20因为这里的增长态势，对吧？
00:11:22这当然必须在迁移的基础上额外完成。
00:11:28显然，这是一项巨大的任务。
00:11:33现在它是微软的一部分了，所以它不是什么小创业公司，
00:11:37但即便如此，这依然是一项艰巨的任务。
00:11:39这是整个 GitHub 问题的其中一个方面，
00:11:44对此我表示同情，因为我认为
00:11:47黑 GitHub 或者嘲笑 GitHub 很容易。
00:11:51你当然可以这么做。
00:11:52稍后我会谈到更多非常严重的问题。
00:11:56但这种流量增长对任何系统、
00:11:59对世界上的任何公司来说都会是巨大的挑战。
00:12:03很难相信 GitHub 的任何竞争对手
00:12:07在这种情况下能做得更好。
00:12:09尽管如此，这当然不是借口。
00:12:10它是微软的一部分。
00:12:12因此，他们肯定有足够的资源
00:12:16来完成这种转型，并调整他们的系统
00:12:20以适应这个新世界和新的流量规模。
00:12:24但 GitHub 还有另一个重要的问题。
00:12:28那就是它不再有 CEO 了。
00:12:32前任 CEO Thomas，即 Thomas Domke，
00:12:37在 2025 年 8 月退休、离职，
00:12:41或者是宣布了他将离职的消息。
00:12:43而微软并没有委派新的 CEO。
00:12:48相反，GitHub 成为了 Core AI 的一部分，
00:12:51这是微软的一个内部部门，顾名思义，
00:12:56它完全专注于 AI 以及构建 AI 工具和平台。
00:13:01而 GitHub 就是其中的一部分。
00:13:03所以很明显，从微软的角度来看，GitHub 的使命
00:13:07就是成为 AI 工具链的一部分，
00:13:11成为 AI 革命的一部分。
00:13:13显然微软正在将 Copilot
00:13:15推向他们所有的产品。
00:13:16事实上，在 GitHub Universe 2023 上，
00:13:20他们已经表示将把 GitHub
00:13:24转型为由 AI 驱动的开发者平台，
00:13:28让 GitHub 无处不在。
00:13:30这包括一些新功能，
00:13:32比如通过 GitHub Copilot 协助创建 Issue，
00:13:36这对开源维护者来说是个巨大的麻烦，
00:13:39但也包括 GitHub Copilot 在 GitHub 上
00:13:43纯粹的无处不在。
00:13:44GitHub 上有一个叫 Agent HQ 的东西，
00:13:48即 [github.com/copilot](https://github.com/copilot)，
00:13:49你可以在那里与 GitHub Copilot 交互，
00:13:52直接在 GitHub Copilot 内部编写代码，
00:13:55而无需打开本地 IDE 或编码代理工具，
00:14:00还有很多很多其他部分。
00:14:02GitHub Copilot 在 GitHub 中无处不在，
00:14:05就像 Copilot 在微软所有产品中
00:14:07都无处不在一样，我猜。
00:14:10这当然是一个清晰的战略决策，
00:14:14这在某种程度上背离了 GitHub 的实际使命，
00:14:19至少是 GitHub 过去的使命。
00:14:23因为正如我在一开始提到的，
00:14:25GitHub 对于不同类型的开发者
00:14:29和各种应用场景都很重要。
00:14:31开源维护者用它来托管源代码，
00:14:36并与其他维护者以及来自
00:14:39社区的其他贡献者进行协作。
00:14:41Issue 对于发现问题、
00:14:45以及解决问题至关重要。
00:14:46Pull Request 对于让其他人
00:14:50为代码库做出贡献非常重要。
00:14:52Discussion 对于讨论新功能、
00:14:55代码仓库或库的发展方向等非常有帮助。
00:15:01这里有很多相关功能
00:15:03可以帮助开源维护者，
00:15:04或者至少在过去是很有帮助的。
00:15:07其他人只是把 GitHub 当作
00:15:11托管链接或文档的资源，
00:15:13比如那些 awesome 系列仓库，awesome Go, awesome Rust 等等，
00:15:17如果你想学习 Go 或 Rust，
00:15:20可以通过它们轻松找到资源。
00:15:22我也使用 GitHub 来托管我的课程资源，
00:15:26比如我的 Codex 课程，
00:15:29以及许多其他课程也一样。
00:15:31所以你甚至可以“滥用” GitHub，
00:15:33把它单纯当作一种文档存储。
00:15:36当然，你还可以将 GitHub 用于 CI/CD 工作。
00:15:40在公司里，你可能会使用 GitHub
00:15:43来托管你的源代码，
00:15:46让团队成员通过 Pull Request
00:15:50等方式协作开发代码。
00:15:52此外，GitHub 通常
00:15:54也是 CI/CD 流水线的一部分，
00:15:57例如，向主分支提交新的推送
00:15:59会触发 CI/CD 流水线。
00:16:02这可以借助 GitHub Actions 来实现，
00:16:05虽然那个产品也有它自己的问题。
00:16:08但当然，它也可以触发
00:16:12任何其他 CI/CD 提供商的流水线，而不只是 GitHub Action。
00:16:16所以 GitHub 对于经典的传统开发工作
00:16:20显然扮演着非常重要的角色。
00:16:24但是，微软决定不，
00:16:27它应该成为一个 AI 驱动的开发者平台，
00:16:31而不只是一个开发者平台。
00:16:33这在某种程度上形成了一种错位。
00:16:37开发者并不一定希望 Copilot
00:16:41出现在 GitHub 的方方面面。
00:16:43我猜微软产品的普通用户
00:16:46也不希望 GitHub 出现在他们所有的产品中，
00:16:48但那是另一回事了。
00:16:49GitHub 一直在忽视那些
00:16:53对开发者来说至关中心的核心功能。
00:16:56我是说，拿开源开发工作举例。
00:17:00开源项目的维护者们正淹没在
00:17:03AI 生成的 Issue 和拉取请求（PR）中。
00:17:07当然，这里的问题在于不对称性。
00:17:10使用 AI 来生成代码或 Issue 非常容易，
00:17:14但审核这些内容却要困难得多。
00:17:19也就是去审核那些生成的代码和 Issue。
00:17:24我的意思是，任何接触过 AI 的
00:17:26开发者都深有体会。
00:17:27你可以轻松启动三个或更多的 AI Agent
00:17:30让它们在你的项目中工作，
00:17:32这完全可以在 GitHub 之外完成。
00:17:33你可以在自己的机器上使用 Codeium、
00:17:35Claude Code 等工具。
00:17:36但如果你不打算走“盲目编码”的路线——
00:17:39在我看来你也不应该这么做——
00:17:41你最终还是得在某个时刻审核那些代码。
00:17:44而这需要花费时间。
00:17:45而且这一点也不好玩，至少对我来说是这样。
00:17:48现在，如果你启动了三个 Agent，
00:17:51你就得审核三个 Agent 的产出。
00:17:54如果负担太重，或者你发现这种方式
00:17:57并不能真正提高效率，
00:17:59你可以减少 Agent 的数量。
00:18:00然而，当你作为 GitHub 上的开源维护者时，
00:18:03你正淹没在 AI 生成的 Issue 和 PR 中，
00:18:07而你通常只有两个主要选择。
00:18:09你可以忽略它们，但这当然违背了它们的初衷，
00:18:13但显然这确实是一个有效的策略。
00:18:16或者你试着去处理它们，
00:18:18结果却因为量太大而精疲力竭，
00:18:21因为这和你个人的开发工作不同，
00:18:25你无法简单地减少涌入的
00:18:29Issue 和拉取请求。
00:18:30如果你觉得自己无法有效地处理
00:18:33这么多正在运行的 Agent，
00:18:36你可以减少自己使用的 Agent 数量。
00:18:38但在公共仓库里，你没法这么做。
00:18:41你无法控制会有多少人提交
00:18:45AI 生成的 Issue 或向你发送 PR。
00:18:49所以这对开源维护者来说是一个巨大的问题，
00:18:53也是为什么整个开源生态
00:18:56及其背后的哲学
00:18:59现在正因 AI 而陷入巨大的困境。
00:19:04而 GitHub 对此并无助益。
00:19:06相反，他们正在反其道而行之。
00:19:08他们正在积极降低发布
00:19:13AI 垃圾（slop）Issue 等内容的门槛。
00:19:15维护者和开发者真正需要的，
00:19:18是处理这些 AI 生成的
00:19:22Issue 和拉取请求的更有效的工具。
00:19:25但 GitHub 并没有在研发这些。
00:19:27我猜这并不在他们的战略范围之内。
00:19:29也许以后会有所改变。
00:19:30我之前提到的 GitHub 那篇官方公告
00:19:35主要讨论的是可靠性和运行时间问题，
00:19:39以及他们希望变得更加透明等等。
00:19:41但他们也提到了支持开发者的
00:19:44承诺。
00:19:46我们拭目以待吧，但我不太乐观，
00:19:49因为归根结底它是微软的一部分，
00:19:52而微软有他们自己的战略。
00:19:55但这对 GitHub 意味着什么呢？
00:19:59是时候迁走了吗？
00:20:02我在 X 平台上偶尔会听到一些声音，
00:20:05说现在是寻找 GitHub 替代品的时候了。
00:20:08我知道有些项目已经迁走了。
00:20:12Zig 可能是最著名的例子。
00:20:15他们在 2025 年 11 月从 GitHub 迁到了 Codeberg。
00:20:20但我们要现实一点。
00:20:22首先，正如我之前提到的，
00:20:24GitHub 承载的巨大流量
00:20:28同样也会压垮任何竞争对手。
00:20:31甚至可能比压垮 GitHub 还要快，
00:20:32因为他们背后没有微软撑腰。
00:20:35所以我们绝对不会看到 GitHub 被取代。
00:20:40虽然一些特定的项目，
00:20:42尤其是开源项目，可能会出于
00:20:45我完全可以理解的原因离开 GitHub，
00:20:48但那些公司和大多数个人开发者
00:20:52很可能不会迁走。
00:20:54尽管存在各种问题，GitHub 仍然拥有
00:20:57功能丰富的平台，其中的许多功能已深入
00:21:02许多开发者的工作流和日常工作。
00:21:06尤其是对于公司来说，
00:21:08要将 GitHub 替换成其他供应商
00:21:11绝非易事。
00:21:13尽管所有的可靠性故障
00:21:15对公司来说显然也是巨大的问题，
00:21:18但在考虑搬迁之前，他们有能力
00:21:23也愿意承受更多的痛苦。
00:21:25这一点我很确定。
00:21:26GitHub 实在是太重要了。
00:21:30它是将你用 Git 管理的代码存入云端，
00:21:35并在此基础上进行开发和协作的终极平台。
00:21:39所以我确信它不会消失，
00:21:43即便情况变得更糟。
00:21:45当然，如果 GitHub 真的无动于衷，
00:21:47人们最终还是会离开，
00:21:49但显然他们正在采取行动，
00:21:50至少在解决运行时间和可靠性问题上。
00:21:55至于开源工作面临的那些问题
00:21:58以及 AI 垃圾 Issue，我们还得观察。
00:22:01即便在那些方面，我也认为 GitHub 太重要了，
00:22:07对开源维护者来说优势太大，
00:22:10不太可能集体离开。
00:22:14但我完全理解如果某些个人项目
00:22:17决定迁出 GitHub，这确实可能会发生。
00:22:20但对于公司和 GitHub 整体而言，
00:22:23它会一直存在下去。
00:22:24尽管如此，我们只能希望目前这种局面
00:22:28或许能成为微软的一个警钟。
00:22:33也许他们会重新任命一位 GitHub 的 CEO。
00:22:38他们也许会意识到它的重要性。
00:22:41他们也许会明白这是一个属于开发者
00:22:45和开发工作的平台，而非首要的 AI 平台。
00:22:49不过，这也只能是希望。
00:22:52我不知道这是否会发生，以及何时会发生。
00:22:55但无论如何，这就是 GitHub 目前的情况。
00:23:00很糟糕，真的很糟糕。
00:23:03而且在短期内还会继续糟糕下去，
00:23:06但至少可靠性有望在今年晚些时候
00:23:11得到改善。
00:23:13我想，我们只能边走边看。