资深开发者告别GitHub：从18年热爱到无奈迁移

当一位在GitHub上活跃了18年的资深开发者决定离开，这绝非一时冲动。近日，HashiCorp联合创始人、Terraform与Vagrant的作者Mitchell Hashimoto在其个人博客发表了一篇长文，揭示了其核心开源项目Ghostty迁移出GitHub的决定。原因直接而严峻：GitHub近期频繁的故障已严重影响了开发工作的稳定性与连续性。

他的应对措施果断而实际：将其当前最重要的、拥有超过5.2万Star的开源项目Ghostty的代码仓库，正式迁出GitHub平台。

Ghostty项目简介：一款备受瞩目的终端模拟器

首先了解一下主角Ghostty。这是一款使用Zig语言编写的现代化终端模拟器，旨在为macOS和Linux用户提供快速、功能全面且具备原生平台体验的解决方案，并计划未来支持Windows。该项目影响力显著，甚至获得了Anthropic的推荐，将其作为Claude Code的首选终端环境。

Mitchell Hashimoto在博客中透露，他是GitHub的第1299位注册用户，账户创建于2008年2月。在随后的18年里，他几乎每天都会多次访问GitHub。可以说，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的诸多功能（如Actions、Issues等），迁移工作无法一蹴而就，将采取分阶段实施的策略。

GitHub近期稳定性问题分析

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

孤立地看，每个技术故障都可能发生；但当故障频率高到足以持续干扰日常开发工作时，问题的性质就发生了根本变化。

更值得关注的是，众所周知，GitHub近年来正大力投入AI功能的开发，例如Copilot、自动化代码分析等。与此同时，其母公司微软的整体战略也在向人工智能领域大幅倾斜。这不禁让许多开发者产生疑问：当平台资源不断向前沿的AI功能倾斜时，最基础、最核心的代码托管与协作服务的稳定性保障，是否受到了忽视？

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

未来展望：若GitHub改善，仍愿回归

在博客的结尾，Hashimoto留下了一段沉重的告别语：“我希望GitHub能变得更好，但我更想专注地编写代码。现在，我已经无法继续依赖GitHub来安心写代码了。很抱歉，在18年后，我不得不选择离开。”

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

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

不过，正如前文所述，迁移Ghostty并非故事的终点。Hashimoto明确表示，如果未来GitHub能拿出切实可见的改进成果，而不仅仅是口头承诺，他依然愿意考虑回归。

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