如果我可以打造自己的 GitHub

背景

本文源於作者對現代程式碼代管平台（Forge）現狀的深切不滿，認為 GitHub、GitLab 等主流工具已逐漸背離 Git 的去中心化初衷，轉而成為臃腫且過度依賴中心化伺服器的產品。作者構思了一個理想中的開發平台，應具備更輕量、更符合現代開發流程且不被大型企業利益綁架的特性，這引發了 Hacker News 社群對於開發工具演進、CI/CD 流程優化以及去中心化替代方案的熱烈討論。

社群觀點

社群對於作者提出的「理想平台」反應兩極，部分開發者認為現有的 Pull Request（PR）流程確實存在結構性缺陷。有留言指出，目前的 PR 討論過於聚焦在留言而非程式碼本身，且 GitHub 處理爭議性討論的方式極其混亂，常透過隱藏部分對話來規避噪音，反而導致追蹤困難。此外，開發者普遍對「提交後才回饋」的循環感到疲憊，認為頻繁出現的修正性提交（如 fix、please 等無意義訊息）反映了現有 CI 系統與本地開發環境的脫節。雖然有人提議透過 pre-commit hook 在推送前執行遠端測試，但也有反對意見認為，若測試速度夠快，開發者本就應在本地執行；若測試過慢，無論是在 PR 階段還是 pre-commit 階段攔截，都無法解決開發者因等待而產生的焦慮。

針對替代方案，社群展開了技術性的辯論。有觀點認為自建服務如 Gitea 或 Forgejo 已能解決大部分問題，但也有人反駁這些工具大多只是 GitHub 的仿製品，缺乏真正的流程創新。討論中特別提到了 Tangled.org 等新興專案，其嘗試將 Jujutsu (jj) 作為版本控制系統，並支持堆疊式 PR（Stacked PRs），試圖打破傳統 PR 的線性限制。然而，安全性與私有倉庫的支援仍是這類實驗性工具的硬傷。另一派意見則將矛頭指向微軟對 AI 的全面押注，認為這導致 GitHub 的核心穩定性與用戶體驗退居二線，甚至出現了對開發者工作流的干擾，這也是 Ghostty 等知名專案選擇離開 GitHub 的主因。

有趣的是，關於「信任」的討論也成為焦點。有開發者質疑，如果一個專案缺乏高信任度的維護者體系，那麼無論工具如何演進，都難以回到 Linux 核心開發那種純粹的郵件列表模式。社群中亦有聲音呼籲將評論、議題追蹤等元數據直接存儲在 Git 倉庫中，以實現真正的去中心化與抗審查性，避免像 XZ Backdoor 事件中微軟直接關閉整個倉庫導致資訊遺失的情況再次發生。然而，這種做法的挑戰在於如何平衡存儲效率與跨倉庫的協作需求，以及如何克服平台方為了增加用戶黏著度而刻意製造的封閉生態。

延伸閱讀

在討論中，社群成員提到了幾個值得關注的工具與專案：Tangled.org 是一個嘗試結合 jj 版本控制與輕量化伺服器的實驗性平台；Radicle 則被提及作為更完整的去中心化協作方案。針對議題追蹤的本地化，有開發者分享了 git-issues 專案，旨在將議題直接存儲於倉庫內。此外，對於不滿意 GitHub 介面的用戶，Codeberg 被視為一個基於 Forgejo 的非營利替代選項。針對行動端開發，甚至有留言分享了利用 AI 工具（如 Claude）對閉源 APK 進行反編譯並成功整合 Audiobookshelf 功能的極端案例，展示了現代開發者利用 AI 繞過平台限制的可能性。