摘要： Mitchell Hashimoto 於 2026 年 4 月 28 日宣布 Ghostty 要離開 GitHub，原因不是 Git，而是 issues、PR 與 Actions 等服務在過去一個月幾乎每天發生影響工作的停機。他表示遷移會漸進推進，GitHub 會留下唯讀鏡像，新平台尚未公布。
2026 年 4 月 28 日,Ghostty 終端機的作者、HashiCorp 共同創辦人 Mitchell Hashimoto 在自家部落格宣布:Ghostty 要離開 GitHub。他的帳號於 2008 年 2 月開通,是這個平台上的第 1,299 位使用者,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 的日誌法——每天如實記下平台故障造成的損失——是整起事件裡最值得借走的工具:它把平台風險化為能夠量化的數字,不再是含糊的不安。