Ghostty迁移启示录：GitHub频繁宕机后，5.2万星顶流项目的官方推荐替代方案与迁移指南

一个老用户的告别：从热爱到失望

当一位在GitHub上活跃了18年的资深开发者决定离开，这绝非轻率的决定。近日，HashiCorp联合创始人、Terraform与Vagrant的作者Mitchell Hashimoto在其个人博客发表了一篇深度长文。核心原因直接而尖锐：GitHub近期频繁的故障，已使其服务稳定性降至无法接受的水平。

他的应对措施同样果断：将其当前最重要的开源项目——拥有5.2万Star的Ghostty，正式迁出GitHub平台。

Ghostty项目：为何备受关注

首先了解项目本身。Ghostty是一款采用Zig语言编写的终端模拟器，旨在为macOS与Linux用户提供高速、功能全面且平台原生的体验，并计划未来支持Windows。其影响力显著，甚至获得Anthropic的推荐，作为Claude Code的首选终端工具。

Hashimoto在博客中透露，他是GitHub的第1299位用户，注册于2008年2月。此后的18年里，他几乎每日都会多次访问GitHub。可以说，这个平台贯穿了他职业生涯的绝大部分。

回顾过去，GitHub曾是他无论身处何地都愿意沉浸的“数字家园”：大学时期熬夜编码后，总会提交一次commit；度假时会收藏大量仓库，研究他人的协作模式；甚至在蜜月期间，也会利用清晨时间查看GitHub动态。

他早年开发Vagrant的重要动力之一，便是希望借此获得GitHub的工作机会。20岁时他曾公开表示：“如果这个项目足够出色，或许GitHub会雇用我。”尽管最终未能加入，但在他心中，GitHub长期代表着开发者理想的协作圣地。

数据记录：近乎“每日宕机”的稳定性危机

那么，究竟是什么让这位“骨灰级”用户最终失去信心？并非单一事件，而是持续影响核心工作流的系统性“不稳定”。

为了客观评估，Hashimoto采取了一种典型的工程师方法：记录数据。在过去一个月中，每当GitHub出现故障并阻碍其工作时，他就在当天的日期旁标记一个“X”。

结果令人震惊：标记几乎覆盖了每一天。

这些问题绝非轻微卡顿，而是直接冲击开发流程的关键环节：GitHub Actions失效导致CI/CD管道中断；Pull Request页面卡死使代码审核停滞；页面加载异常让日常操作难以进行。就在他撰写博客当天，GitHub Actions的故障导致其近两小时无法进行PR审核。

对于轻度用户，这可能只是短暂不便；但对于深度依赖GitHub完成开发、测试、部署全流程的项目而言，此类中断等同于工作被强行阻断。

由此得出的结论无可争议：如果一个平台每天都会阻碍你数小时的工作，它便不再适合用于严肃的软件开发。Hashimoto在博客中写下了这样一段充满挫败感的话：

“我想留在这里，但它不让我留下。

我想完成工作，但它不让我完成。

我想发布软件，但它不让我发布。”

对于一个与平台深度绑定18年的人而言，这已超越了普通抱怨，意味着根本性的信任破裂。Hashimoto甚至承认，近期的愤怒掺杂了个人情感——正因曾“过度热爱一个产品”，如今的失望才尤为深刻。

迁移启动：Ghostty成为“首个撤离项目”

在具体行动上，Hashimoto并未采取全盘否定的激进策略。他的方案务实且渐进：将受故障影响最严重的Ghostty项目逐步迁移至新平台；在GitHub上保留只读镜像仓库，方便现有用户访问；其他个人项目则暂时维持现状。

这更像是一次“核心业务迁移”，而非情绪化的彻底决裂。

选择Ghostty作为首个迁移对象，原因非常实际：它是Hashimoto本人、维护团队及开源社区受GitHub故障影响最直接、最严重的项目，因此必须优先处理。

关于迁移目的地，Hashimoto表示尚未最终确定，团队正与多个候选平台沟通，包括商业服务与自由开源方案。由于项目已深度集成GitHub的诸多功能，迁移工作将分阶段进行，无法一步到位。

深度分析：GitHub究竟出了什么问题？

过去，GitHub作为“开发者基础设施”的地位几乎无可撼动，其生态覆盖了代码托管、协作流程到CI/CD体系。但近期，稳定性问题确实呈现高发态势：GitHub Actions多次中断、PR流程异常、API响应不稳、页面加载失败……例如在4月底，一次由Elasticsearch配置问题引发的事故，就导致大量Pull Request无法正常完成。

孤立看待，每个问题或许都不罕见；但当故障频率高到足以干扰日常工作时，问题的性质就发生了改变。

更值得关注的是，GitHub近年来正大力投入AI能力建设，例如Copilot、自动化代码分析等。与此同时，其母公司微软的整体战略也大幅向AI倾斜。这引发了许多开发者的疑问：当平台资源不断向前沿的AI功能倾斜时，最基础的代码托管与协作稳定性保障是否被忽视了？

目前虽无直接证据表明两者存在因果关系，但至少在时间线上，它们有所重叠。Hashimoto本人并未明确指责这一点，但他的遭遇，确实发生在这个宏观背景之下。

未来展望：回归的可能性与条件

在博客结尾，Hashimoto留下了一段沉重的告别：“我希望GitHub变得更好，但我也想写代码。如今我已无法继续依赖GitHub来写代码了。抱歉，18年后，我不得不离开。”

在Hacker News的后续回应中，他透露了一个细节：撰写那篇博客时，自己甚至落泪，泪水一度滴在键盘上。“说来奇怪，谁会为一个SaaS平台哭泣？但GitHub对我而言远不止于此。我们之间存在着一种不健康的依恋关系。它给予我太多，我对此深怀感激。但，它已不复从前。”

他表示，直到真正点击发布按钮的那一刻，这场离别才显得无比真实。

不过，正如前文所述，迁移Ghostty并非终点。Hashimoto明确表示，如果未来GitHub能展现出实质性的改进成果，而非空头承诺，他依然愿意考虑回归。

参考链接：https://mitchellh.com/writing/ghostty-lea ving-github