2026 年 4 月 28 日,Ghostty 終端機作者、HashiCorp 共同創辦人 Mitchell Hashimoto 在個人部落格宣布:Ghostty 將撤離 GitHub。他自 2008 年 2 月註冊,是第 1,299 位 GitHub 使用者,每天使用這個平台長達 18 年。讓他決定離開的不是 Git,而是 issues、PR 與 Actions 等周邊服務的連環故障——過去一個月,他在日誌上為「被 GitHub 停機傷害的每一天」畫上一個 X,結論是「幾乎每一天都有 X」。這篇文章隨即衝上 Hacker News 首頁,拿下 3,521 分與 1,051 則討論,成為當週開發者圈最大新聞。
這件事之所以重要:GitHub 是全球最大的程式碼託管平台,多數團隊的 PR 流程、CI 與專案管理都長在上面。當一線開源專案的維護者公開以「可靠性」為由出走,等於對整個產業敲了一記警鐘:平台核心服務一旦不穩,你的交付流程就跟著停擺。
停機日誌上的 X
Hashimoto 描述自己過去一個月的工作日誌:只要當天 GitHub 的故障影響到他的工作,就畫一個 X。「幾乎每一天都有 X。」寫文章當天,一次 GitHub Actions 故障讓他無法審 PR 約兩個小時;4 月 28 日另一起事故則因 Elasticsearch 問題導致 pull request 全面失敗。他把結論說得很白:如果這個地方每天都把你擋在外面幾個小時,它就「不再是認真做事的地方」。
壓垮信任的不是 Git,是周邊服務
特別值得注意的是他劃出的界線:出問題的不是 Git。Git 是分散式版本控制,本來就能離線運作;壞掉的是 GitHub 營利的那一層——issues、pull requests、Actions 這些 SaaS 服務。Hashimoto 的批評不是「放棄版本控制」,而是「把協作基礎設施外包給一家穩定性下滑的廠商,代價正在上升」。他對 GitHub 的感情也寫得直接:「因為 GitHub 每一天都在讓我失望,而這件事對我來說是個人的。我想出貨軟體,它卻不想讓我出貨。」
下一個家還沒選定
不同於許多高調遷移,Hashimoto 並未宣布新東家。他說仍在與「多家供應商(商業與 FOSS 都有)」洽談,細節要等之後幾個月才會公布。確定的是三件事:遷移會「盡可能漸進式」進行;GitHub 上會保留一個唯讀鏡像,維持現在的網址;他的個人專案暫時留在 GitHub,因為 Ghostty 才是維護者與社群受衝擊最大的地方。他也為先前對 GitHub 的公開批評道歉,但強調唯有「真正的結果與改善,而不是言語與承諾」,才能讓他考慮回來。
把開發流程押在單一 SaaS 上的風險
The Register 的報導提供另一層脈絡:微軟收購 GitHub 後的種種恐慌「大體上並未成真」,但近年平台不穩定性上升,恰好與微軟把重心轉向 AI 的時間點重疊——同一段時間,該媒體還追蹤了強制 CLI 遙測、Copilot 因容量吃緊暫停註冊等爭議。對產品團隊的啟示很實際:你的開發產線本質上是一條 SaaS 供應鏈,PR review、CI、issue tracking 任一環節停機,都會直接吃掉工程師的時間,而這種損失很少被計入任何帳面成本。
遷移前團隊該先盤點的三件事
第一,確認 Git 工作流可以完全離線運作:本地 clone 與 bundle 備份是任何遷移的底線。第二,把「平台綁定」列出來——Actions workflow、issue 範本、機器人整合、SSO,這些才是真正的遷移成本,程式碼本身永遠是最容易搬的部分。第三,先想好事件應變:如果明天 PR 流程停兩小時,團隊有沒有備援?對多數團隊而言,不需要跟著出走,但需要一份「如果 GitHub 明天不可用」的劇本。Hashimoto 的日誌法——每天記錄平台故障造成的實際損失——本身就是最值得抄走的工具:讓平台風險變成可量化的數據,而不是模糊的不安。
參考來源
- Ghostty Is Leaving GitHub — Mitchell Hashimoto
- HashiCorp co-founder says GitHub ‘no longer a place for serious work’ — The Register
- Ghostty is leaving GitHub — Hacker News
本文由 AI 協助自上述來源整理，經人工審核後發布。