背景

這篇討論源於一篇探討軟體組態管理（SCM）演進的文章，作者主張在 LLM 時代，傳統以檔案系統為核心、基於行比對的 Git 已成為開發效率的阻礙。他提議將代碼庫視為一種結構化的資料庫，利用抽象語法樹（AST）與衝突解決複製資料類型（CRDT）技術，建立一個能理解代碼語義、支持大規模單一倉庫（Monorepo）且具備強大查詢能力的全新版本控制系統。

社群觀點

Hacker News 的討論呈現出對 Git 現狀的集體反思與對新技術路徑的激辯。許多資深開發者認同 Git 在處理大型二進位檔案、跨模組拆分與合併（Monorepo 痛點）以及缺乏語義感知方面的侷限性。支持者認為，隨著 AI 代理人生成代碼的吞吐量大幅提升，開發者的工作重心已從編寫轉向理解與審閱，因此 SCM 確實需要從單純的內容定址檔案系統，進化為能記錄開發意圖、提示詞（Prompts）與代碼演進邏輯的資料庫。

然而，反對意見主要集中在「相容性」與「必要性」兩大層面。部分評論者指出，Git 的價值不在於其 CLI 工具是否好用，而在於它已成為全球軟體協作的底層協議與基礎設施。若新系統不具備與 GitHub 相容的橋接能力，即便技術再先進也難以跨越採納門檻。更有觀點質疑，Git 的儲存模型其實足夠靈活，許多所謂的「資料庫特性」或「語義比對」完全可以作為外掛工具或中間層來實現，而不必徹底捨棄現有的 Merkle 樹架構。

關於「結構化編輯」與「AST 儲存」的爭論尤為激烈。有開發者分享了 Smalltalk 或 Unison 等語言的經驗，認為將代碼存儲為結構化節點能解鎖強大的重構與查詢功能，消除無意義的空白字元衝突。但另一派意見則提醒，文本形式之所以長盛不衰，是因為它能容忍「中間錯誤狀態」，而嚴格的 AST 儲存往往要求代碼在任何時刻都必須符合語法，這在實際開發流程中可能反而增加摩擦。此外，針對 Monorepo 的管理問題，社群也反思這究竟是 Git 的技術限制，還是企業內部流程與依賴管理混亂所導致的結果。

整體而言，社群達成了一種微妙的共識：雖然 Git 並非完美，但它已成為像 Unix 一樣難以撼動的標準。未來的突破口可能不在於完全取代 Git，而是在其之上建立更聰明的語義層，或是開發出能同時兼顧文本靈活性與資料庫結構性的混合型工具。

延伸閱讀

在討論中，參與者提及了多個值得關注的實驗性項目與技術：

• Unison: 一種將函數視為內容定址 AST 儲存的程式語言。
• Dion: 嘗試以結構化資料庫而非文本檔案來儲存程式碼的實驗性專案。
• Trustfall: 一種能將檔案與代碼當作資料庫進行查詢的查詢引擎。
• Difftastic: 基於語法解析而非行比對的結構化比對工具。
• JJ (Jujutsu): 一種試圖改善 Git 操作體驗但保持相容性的新一代版本控制前端。
• Zed DeltaDB: 編輯器 Zed 所採用的基於 CRDT 的協作與儲存機制。