Ghostty 要离开 GitHub，但不是今天就搬空。
项目作者 Mitchell Hashimoto 宣布，Ghostty 将逐步迁出 GitHub。新去向还没定。他说仍在和多个商业及 FOSS 提供方讨论，未来数月会公布更多细节。当前 GitHub 地址会保留只读镜像。
反常点在这里：Hashimoto 不是偶尔抱怨平台体验的新用户。他是 GitHub 早期用户，账号编号 1299，2008 年 2 月加入，18 年来高频使用 GitHub。这样的人公开切割，信号比“又一个项目换托管平台”要重。
我更在意的是：他不满的不是 Git 本身，而是 GitHub 已经变成开源项目的协作入口后，可靠性没跟上这个角色。
Ghostty 为什么决定离开 GitHub
Hashimoto 给出的直接理由很具体：过去一个月，他记录 GitHub 故障是否影响工作，结果几乎每天都有负面标记。
他写文章当天，GitHub Actions 出故障，导致约 2 小时无法进行 PR review。对维护者来说，这不是页面慢一点，而是审代码、跑测试、合并变更都被卡住。
他还特意澄清，文中说的故障并不是 2026 年 4 月 27 日那次大型 ElasticSearch 事故。文章写于更早一周。也就是说，他不是抓着单一事故发泄，而是在描述一段时间内反复被打断的维护体验。
这点很关键。
如果只是一次宕机，大项目通常会忍。可如果 issue 分拣、PR review、CI、发布流程经常被打断，维护者每天都会付出额外切换成本。开源维护本来就靠碎片时间和稳定节奏撑着，工具一抖，人的耐心先掉。
问题不在 Git，而在 GitHub 的协作层
很多人看到“离开 GitHub”，容易理解成“代码托管换家”。这次不是这么简单。
Git 是分布式版本控制。代码仓库本身可以镜像、复制、迁移。真正难搬的是 GitHub 围绕仓库长出来的协作设施：issues、Pull Requests、GitHub Actions、权限、发布脚本、贡献者习惯。
| 受影响环节 | GitHub 依赖 | 对维护者的实际影响 |
|---|---|---|
| 问题管理 | issues | bug、需求、用户反馈难以及时分拣 |
| 代码评审 | Pull Requests | review、讨论、合并节奏被打断 |
| 自动化流程 | GitHub Actions | 测试、构建、发布无法稳定推进 |
| 仓库本体 | Git | 原文没有把问题归咎于 Git |
这也是 GitHub 今天的矛盾。
它早就不是“放代码的网站”。对许多开源项目来说，它同时是工单系统、评审系统、CI 平台、社区入口和发布通道。便利集中在一个地方，风险也集中在一个地方。
所以这件事不能简单写成反 Microsoft，也不能写成反商业平台。原文没有给出这种理由。Hashimoto 的核心抱怨是可用性：他想写代码、审 PR、发软件，但平台频繁挡在中间。
迁移会慢慢发生，最该动的是风险预案
Ghostty 的迁移不会一键完成。Hashimoto 说得很清楚：未来数月会公布去向，当前 GitHub 仓库会保留只读镜像。他的个人项目和其他工作暂时仍留在 GitHub，迁移重点限于 Ghostty。
这说明他不是情绪化清仓，而是在给一个活跃项目重新接线。
可选路线也没有完美答案。GitLab、Codeberg、SourceHut，以及自托管 Forgejo/Gitea，都能承接一部分需求，但代价不同。
| 路线 | 可能收益 | 现实约束 |
|---|---|---|
| 商业平台 | 迁移和协作体验相对完整 | 仍要承担平台故障和锁定风险 |
| FOSS 托管方 | 理念和开源项目更贴近 | 规模、稳定性、生态工具要重新评估 |
| 自托管 | 控制权更高 | 可用性、备份、安全、反滥用都要自己扛 |
对开源项目维护者，这件事最直接的动作不是马上搬家，而是先盘点依赖：issues 在哪，CI 在哪，release 怎么发，权限怎么管，故障时有没有替代路径。
如果一个项目的测试、构建、发布全压在 GitHub Actions 上，至少要准备可复现的本地构建脚本，或者能切到另一套 CI。别等发布当天才发现，流水线坏了就没人能发版。
对依赖 GitHub 协作与 CI 的开发团队，动作也很具体：重要版本发布前，不要只看代码冻结时间，也要把平台状态纳入发布检查；关键仓库要做镜像；关键 issue 和 release 记录要能导出；采购或选型时，不能只比较功能，还要问 SLA、故障通报和数据迁移路径。
接下来真正要看的不是“Ghostty 最后去了哪”这么简单。
更该看三件事：历史 issues 和贡献记录如何保留；新 PR 和 CI 流程会不会抬高贡献门槛；GitHub 会不会用可见的稳定性改进回应这类重度用户的批评。
Hashimoto 留了一扇门：如果 GitHub 未来拿出真实结果和改进，他愿意回来。但对 Ghostty 来说，等待承诺已经不如先把关键工作流移出去。
这就是这次迁移最扎眼的地方。一个 18 年老用户不是不用 GitHub 了，而是不再愿意把最重要的协作节奏全押在它身上。