GitHub重建Git底層：5000個AI並行工作，單倉庫每秒處理7200次程式碼推送

動察 Beating AI 快訊，GitHub 公佈了代號為 Rubicon 的新一代 Git 存儲架構。內部測試顯示，5000 個 AI Agent 可以同時在一個代碼倉庫中工作，每秒完成 7200 次代碼推送，同時保持較低的讀取延遲。

過去，GitHub 最繁忙的代碼倉庫，每秒也只有短時幾十次寫入。現在，大量 AI Agent 可以全天候並行開發，不斷提交新代碼。每次提交還可能觸發自動測試，讓其他 Agent 下載最新版本，倉庫的讀寫壓力隨之增加。

GitHub 的解決辦法，是把「存代碼」和「更新分支」分開處理。

Git 每次推送代碼，都要完成兩件事。第一步是保存新增或修改後的代碼內容。Git 不會直接覆蓋舊版本，而是把變化的內容存成新對象，沒變的部分可以繼續復用。第二步是更新分支指針，記錄這個分支現在指向哪個最新版本。

比如，1000 個 Agent 同時開發軟件，有的修改登錄功能，有的修改支付功能。只要它們在不同分支工作，新代碼就可以同時保存，分支也能各自更新。只有兩個 Agent 同時爭着更新同一個分支時，系統才需要判斷誰的更新能先成功。

GitHub 最初讓所有分支共用一份更新記錄。即使不同 AI Agent 修改的是不同分支，也要爭着更新同一個文件，導致每秒只能處理數百次推送。GitHub 又試着把記錄拆成多份，讓不同分支同時更新。但這樣一來，每次檢查倉庫有沒有變化，都得逐份查詢，反而拖慢讀取速度。

最終，GitHub 開發了專門管理分支更新的 Ref-CAS 服務。它允許不同分支同時更新，只有修改同一分支時才需要處理衝突。同時，它還給整個倉庫維護一個統一版本號。其他程序只需檢查這個版本號，就能知道倉庫有沒有變化，不必逐個查詢所有分支。

GitHub 另外安排獨立機器，在後台合併不斷積累的代碼數據包，避免數據包越來越多、拖慢讀取。新架構最終在內部測試中達到每秒 7200 次推送。

GitHub 的 Rubicon 目前仍處於有限私測階段，計劃在 2027 年初擴大上線。

原文連結

發佈者對本文章的內容承擔全部責任
在投資加密貨幣前，請務必深入研究，理解相關風險，並謹慎評估自己的風險承受能力。不要因為短期高回報的誘惑而忽視潛在的重大損失。