GitHub 的可靠性危机：故障、合并错误与开发者信任

GitHub 影响了我大约 15 年：我的项目、工作、友谊以及对开源的理解都在这里成长。因此，近期的可靠性问题让我很难受。我在一个工作日的大部分时间里无法加载 T3 Code 所需的 pull request；另一次合并队列事故则让我更担心代码变更能否可靠保留。

页面无法加载已经令人沮丧，而错误的合并可能更加严重：部署可能已经包含某些变更，后续合并却把这些变更从分支中移除。排查运行中的系统与仓库历史为何不一致会很痛苦，尤其是在涉及数据库迁移时。

我也不满意管理层对合并事故的描述。我的批评针对故障的严重性以及问责的必要性。问题已经不只是页面是否缓慢，而是维护者能否信任他们赖以协作和发布软件的基础设施。

一张 GitHub 每月平均报告可用率图表显示出下降趋势，但纵轴从接近 99.5% 开始，报告或测量方式也可能随时间改变。我不会仅凭这张图推断精确的历史趋势；事故如何衡量和图形本身同样重要。

一个独立状态页在任一受跟踪组件发生事故时，就把相应时段算作受影响。视频中，它显示此前 90 天的可用率为 86.75%。这并不表示整个 GitHub 服务有 13.25% 的时间无法访问，而是对组件事故采用了更宽泛的统计方式。

可靠性有几个维度：功能是否仍按昨天的方式运行？需要时能否使用？昨天完成的工作是否仍然完好？其中任何一项变化都可能削弱信任，但已完成的工作消失尤其危险。

我对导航、pull request 性能和命令行体验也有不满，但这些并不是人们考虑离开的直接原因。可用性和正确性更加基础：团队需要发布时，如果服务不可用，依赖它的工作流程就会变得脆弱。

我记得大约在 2022 年出差时遇到的一次故障。有客户需要紧急修复视频服务；我测试并合并了代码，以为 Vercel 集成会自动部署。当时 GitHub webhook 出了问题，部署没有按预期发生。

Webhook 会通知其他服务发生了变化，让一次合并触发构建或部署。那次事故中，我得知有些通知延迟，有些则没有送达。最终我用 Vercel CLI 手动部署。一个服务丢失的事件阻碍了另一个服务的修复。

那次经历开始侵蚀我对一个曾经视为理所当然的平台的信任。对我来说，GitHub 不只是代码浏览器：我通过阅读 issue、pull request 讨论和维护者主页学习。观察人们如何协作，与阅读源代码同样重要。

很长时间里，我认为微软对 GitHub 的管理总体是积极的，包括让免费用户也能使用私有仓库。我继续付费是因为重视这项服务。Git 和 GitHub 是不同的东西，但 GitHub 曾让我觉得几乎和电脑上的 Git 一样可靠。

近期事故让我难以继续维持这种信念。我区分暂时无法使用服务和服务未能保留用户预期状态这两种故障。一次产生错误历史的合并，可能在状态页宣布事故结束后仍留下后果。

设想一下：你合并并部署了包含数据库迁移的变更，随后发现另一次合并把它从分支中移除了。线上系统和分支可能不再一致；盲目再次应用变更还可能让问题更复杂。这就是我认为合并正确性比普通停机更令人担忧的原因。

GitHub 的事后报告称，2026 年 4 月 23 日的回归影响了合并队列中包含多个 pull request 的 squash 合并。后续合并可能意外撤销更早的变更；报告称影响窗口内有 2,092 个 pull request 受影响。官方说明见 https://us.githubstatus.com/posts/details/PXT8RAY。

我读到的首席运营官 Kyle Daigle 的帖子称，当天超过 400 万个已合并 pull request 中有 2,804 个受影响，并表示问题已修复、客户已获联系、测试将得到扩充。后来的事故报告使用了不同数字和更窄的描述，不能把两组数字视为可以直接互换。

我认为那段表述淡化了变更被撤销的实际影响，因此提出异议。以全天合并量计算出的百分比，并不能告诉受影响的团队如何修复仓库。我希望看到对故障的直接解释、道歉，以及防护措施将得到改善的证据。

我对问责的担忧也涉及领导层。录制时，我的理解是 GitHub 前任 CEO 离职后没有另设 CEO，管理层向微软汇报。我认为如此重要的服务需要一位责任清晰的领导者，能够优先保障平台健康。

我也披露：我投资了前 GitHub CEO 的新公司，它正在探索 Git 工作流程，未来可能在这一领域形成竞争。项目仍处早期，而这项投资是我讨论 GitHub 领导层或替代方案时应当交代的背景。

我认为，当公司缺少一位专注产品的统一负责人时，系统性故障更难明确归责。这是我对组织问题的判断，并不能证明任何具体高管有意造成故障，也不能证明外部商业利益导致了这些事件。

我还谈到自己所理解的 GitHub 产品与工程组织之间的分离。我无法从外部确定完整的内部汇报结构，但担忧是实际的：如果负责用户需求的团队与负责系统实现的团队距离太远，重要的可靠性工作就可能落在两者之间。

我在 Twitch 工作时，产品经理与工程团队密切合作。他们不必知道每一个实现细节，但了解产品并参与我们的决策。对于开发者产品，我尤其希望产品和工程之间有紧密协作。

不同的汇报线可以运作，但需要有人有责任和权力协调它们。我的批评是，缺乏有效协调时，各团队可能只优化各自部分，而整体用户体验持续恶化。我希望 GitHub 用可见的改进证明我的判断有误。

另一次安全披露也影响了我的信心。Wiz 研究人员发现 GitHub 处理 Git push 选项时存在远程代码执行漏洞。GitHub 表示，其在两小时内验证报告并修复 github.com，调查没有发现遭利用的证据：https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/。

这个漏洞是在报告和修复之后才公开披露的；潜在影响不能等同于数百万仓库实际遭到入侵的证据。尽管如此，中心化代码托管服务中漏洞的潜在影响说明，快速修复和透明调查非常重要。

Mitchell Hashimoto 宣布 Ghostty 计划离开 GitHub。他写道，自己自 2008 年以来几乎每天都使用 GitHub，把项目从这个工作核心场所迁走令他十分难过。我对此感同身受，因为我也在那里学习并建立了职业生涯。

Hashimoto 描述了自己如何研究维护者对 issue 和 pull request 的回应，而不只是读代码。我也是这样学习的。开源让参与者和工作过程都变得可见，为新人提供了审查、讨论和维护真实软件的范例。

他表示，自己在日记里记录的多数日子都受到重复故障的干扰。宣布时，Ghostty 计划逐步迁移，保留 GitHub 只读镜像，他的个人项目暂时仍留在 GitHub。这是一项计划，并不是说所有项目当时都已迁走。

这则公告令人难受，因为这个平台不仅是托管服务。它为维护者提供了共同工作的场所，也让像我这样的人能够发现项目、找到合作者并展示自己的能力。失去信心意味着要重新考虑整个社区的工作流程。

最近我返回 T3 Code 的 pull request 页面，发现几个小时后仍无法加载。即使平台出现问题，维护者也必须回应用户并审查贡献。我觉得自己有责任为开源社区发声，同时也知道 GitHub 内部有人正在努力解决问题。

我还提到 Tanner Linsley 关于未带 scope 的 npm 包 tanstack 的报告。他说该包不由 TanStack 项目控制，而他曾试图取得这个名称。我讲述了有关同名包携带窃取环境数据脚本的报告。

包名和组织 scope 是不同的：未带 scope 的相似名称不能与项目合法的 @tanstack 包混为一谈。我对此前名称争议及对方动机的描述来自他人告知；恶意代码出现的时间和责任归属需要另行证据。

这让我在可靠性框架中加入第四个问题：平台能否保护用户及其工作免受安全滥用？我的观点是，可用性、一致行为、数据持久性和安全性共同构成信任。平台可以妥善回应某一次事故，但仍需要更广泛的改进。

我提到 GitLab、Gitea 和 Bitbucket 等可能的方向，但这期视频没有给出迁移建议。迁移代码只是工作的一部分：还要考虑 issue 历史、审查、CI、webhook 和项目周围的社区。我计划在后续视频中评估替代方案。

我希望看到责任明确的领导者、更紧密的产品与工程协作，以及具体的可靠性路线图。比起承诺，我更想看到修复实际生效。我的沮丧来自对依赖 GitHub 的人们的关心，也来自希望它重新赢得信任。

目前我无法像过去那样充满信心地推荐 GitHub，因此打算研究替代方案。如果服务得到改善，我很乐意看到自己的判断被证明有误；对我来说，关键是让使用它构建软件的人持续看到可靠性改善。