告別 GitHub

2026 年 4 月 28 日，HashiCorp 聯合創始人 Mitchell Hashimoto 發文宣布，開源終端模擬器項目 Ghostty 將離開 GitHub。

他在文章中寫道，自己是 GitHub 第 1299 位用戶，2008 年 2 月就加入了這個平臺。過去 18 年多，他幾乎每天都會打開 GitHub，甚至一天多次。對他而言，GitHub 不只是一個代碼托管網站，而是開源、工作和個人熱情長期交匯的地方。

Mitchell Hashimoto 的語氣并不輕松。

他稱，寫下這篇文章讓他“莫名地難過”。他回憶，自己曾把 GitHub 視為最快樂、最想待的地方：失戀時沉浸在開源項目里，大學凌晨 4 點提交代碼，甚至蜜月期間也會在妻子睡著后繼續瀏覽 GitHub。Vagrant 這個讓他成名的開源項目，當年也部分源于一個愿望：希望有一天能因此獲得 GitHub 的工作機會。

但這份長期感情最終被穩定性問題消耗掉了。

Mitchell Hashimoto 表示，過去一個月，他開始在日記里記錄每一次 GitHub 宕機影響工作的日期，結果幾乎每天都要打上一個 “X”。

在寫下文章當天，他因為 GitHub Actions 中斷，大約 2 小時無法進行 PR 審核。他的判斷很直接：如果一個平臺每天都讓開發者損失數小時工作時間，那這里就“不再適合嚴肅工作”。

這并不是孤立抱怨。

GitHub 官方狀態頁顯示，4 月 27 日，GitHub 搜索相關服務出現降級，影響 Actions、Issues、Packages 和 Pull Requests 等多個關鍵功能；當天用戶曾遇到 issue、PR、project 和 Actions workflow run 間歇性加載失敗。4 月 28 日，GitHub 又出現 Pull Requests 性能降級，部分倉庫的 PR 頁面無法完整顯示結果，同時 Actions 托管 Ubuntu 作業也出現延遲或失敗。

GitHub 解釋稱，4 月 27 日的事故影響了 Elasticsearch 子系統。該子系統支撐 GitHub 上多個依賴搜索的體驗，包括部分 Pull Requests、Issues 和 Projects。GitHub 表示，集群過載，初步判斷可能與 botnet 攻擊有關；事故沒有造成數據丟失，Git 操作和 API 沒受影響，但依賴搜索的部分界面無法返回結果，造成了明顯中斷。

現代開源項目依賴的早已不只是 Git 倉庫本身。

Issues、Pull Requests、Actions、Packages、Release、搜索、項目管理和社區協作，已經共同構成開發者的日常工作流。核心代碼可以正常拉取，并不意味著開發沒有被打斷。一旦 PR 審核、CI 流水線、搜索和項目管理頻繁出問題，平臺就會從基礎設施變成風險源。

Ghostty 是 Mitchell Hashimoto 近年來投入大量精力的開源終端模擬器項目。Ghostty 是一個快速、功能豐富、跨平臺的終端模擬器，采用平臺原生 UI 和 GPU 加速。Mitchell Hashimoto 也在個人主頁中表示，自己目前主要時間都投入在 Ghostty 上。

按照 Mitchell Hashimoto 的說法，Ghostty 不會立刻“一刀切”遷走。

未來幾個月，團隊會公布更多遷移細節，目前已與多個商業供應商和 FOSS 方案進行深入討論。遷移 GitHub 依賴需要時間，項目計劃逐步完成，并保留當前 GitHub 地址作為只讀鏡像。他的個人項目和其他工作暫時仍會留在 GitHub 上，此次變更主要集中在 Ghostty。

這次事件對 GitHub 的沖擊，不在于一個項目倉庫本身有多大，而在于離開者的身份和語境。

Mitchell Hashimoto 是 HashiCorp 聯合創始人，也是 Vagrant、Terraform、Vault、Nomad 等基礎設施工具背后的重要人物之一。

一個使用 GitHub 超過 18 年、把它視作職業和開源生活中心的開發者公開離場，比普通用戶抱怨更具象征意義。

對 GitHub 來說，這更像一次信任警報。

開發者不是不能接受偶發故障，但無法接受關鍵工作流反復中斷，更無法接受平臺從“每天都想打開的地方”變成“每天都阻礙工作的地方”。

他希望 GitHub 能變好，也希望有一天能回來。但前提不是承諾，而是實際成果和改進。對于 GitHub 而言，真正要挽回的，可能不是 Ghostty 這一個項目，而是開源維護者對這個平臺長期穩定性的信心。

Mitchell Hashimoto 全文。

Ghostty 即將離開 GitHub

寫下這些文字，讓人有些不理性地難過，但 Ghostty 即將離開 GitHub。

我是 GitHub 第 1299 位用戶，2008 年 2 月加入。

從那以后，我每天都會打開 GitHub。每天，一天好幾次，持續了 18 年多。這已經超過了人生的一半時間。中間當然有少數例外，我也很想看看具體數據，但很難想象，一年里不使用 GitHub 的時間會超過一周。

GitHub 是最讓我快樂的地方。總會愿意為它騰出時間。經歷艱難分手時，會讓自己沉浸在 GitHub 上的開源世界里。大學時，凌晨 4 點，大家都睡著了，還會想著再提交一段代碼。蜜月期間，妻子還在睡覺，也會打開 GitHub。很長一段時間里，GitHub 就是最讓人開心、最想待著的地方。

甚至連那些煩人的事情也是如此。有人會刷社交媒體刷到停不下來，而在這個詞出現之前，我就已經在 GitHub issues 里“末日式滑動”了。度假時，也會收藏一些想研究的 GitHub 項目。不只是看源代碼，也會看開源軟件的協作流程，看其他維護者如何處理棘手問題。信不信由你，我就是喜歡這些。

有人可能會覺得這有點病態。但我的愛好、工作和熱情剛好重合，而在我大部分人生里，它們又剛好匯聚在互聯網上同一個地方：GitHub。

你知道嗎？我之所以開始做 Vagrant，也就是第一個真正成功的開源項目，很大程度上是因為希望它能幫我獲得一份 GitHub 的工作。這并不是什么秘密，我已經說過很多次。第一次公開講 Vagrant 時，我才 20 歲。當時我還開玩笑說：“如果 Vagrant 做得不錯，也許 GitHub 會雇我！”

GitHub 曾經是我夢想中的工作。我最后沒有在那里工作過，這不是他們的錯。但那是我最想去的完美地方。那里的工程師很出色，產品也令人驚艷，而我每天都沉浸其中。直到現在也是如此，過去 18 年一直如此。18 年，已經足夠讓一個人在 GitHub 上從少年長成成年人。

最近，我一直在公開批評 GitHub。我說過一些很重的話，也很憤怒，可能傷害了一些人的感情。我確實是在發泄。因為 GitHub 每天都在讓我失望，而這件事對我來說很私人，也不理性地私人。我對 GitHub 的喜歡，已經超過一個人對一件東西應有的喜歡，所以我才會對它生氣。如果傷害了 GitHub 團隊成員的感受，我很抱歉。

這種感受已經持續很久了。但過去一個月，我開始記日記：每當 GitHub 宕機影響我工作，就在那一天旁邊打一個 “X”。幾乎每天都有一個 “X”。就在寫這篇文章的當天，因為 GitHub Actions 中斷，我大約 2 個小時無法進行任何 PR 審查。如果一個平臺每天都讓人被擋在工作之外好幾個小時，那它已經不再適合嚴肅工作。

這里對我來說，已經不再是一個愉快的地方。我想待在那里，但它好像并不想讓我待在那里。我想完成工作，但它不讓我完成工作。我想發布軟件，但它不讓我發布軟件。

我希望它變得更好，但我也想寫代碼。而現在，我已經沒法再依靠 GitHub 寫代碼了。很抱歉。18 年之后，必須離開了。希望有一天還能回來，但這必須建立在真正的結果和改進之上，而不是空話和承諾。

未來幾個月，會分享更多關于 Ghostty 項目將遷往何處的細節。我們已經有了計劃，但仍在與多家服務商深入溝通，包括商業服務商，也包括 FOSS 方案。

移除所有 GitHub 依賴需要時間，我們已經制定了計劃，會盡可能漸進地完成遷移。我們計劃在當前 URL 保留一個 GitHub 只讀鏡像。

我的個人項目和其他工作，目前仍會留在 GitHub。Ghostty 是我、維護者以及開源社區受影響最大的項目，因此這次變化的重點會先放在 Ghostty 上。之后會如何發展，再繼續觀察。

腳注補充：

這次宣布的時間，恰好和 2026 年 4 月 27 日 GitHub 大規模宕機接近，但只是巧合。我們已經討論并制定離開 GitHub 的計劃好幾個月了，這篇文章也是一周多前寫好的，只是本周才做出最終決定。

對那些會說“Git 是分布式的”的人：問題不是 Git 本身，而是圍繞 Git 所依賴的基礎設施，比如 issues、PR、Actions 等。

這也不是 2026 年 4 月 27 日那次大規模 Elasticsearch 宕機。這篇文章是一周前寫的，所以這里說的是另一次故障。