日合併量四個月成長12倍：Anthropic換掉Git，換掉的是為人類速度設計的整套基礎設施

2026年10月13日，Anthropic工程部落格發表文章《Redesigning source control at Anthropic》，披露該公司monorepo的日均合併量從2026年5月的約2,500次，成長到9月的30,000次以上，四個月成長12倍。Git在這個規模下失效，一個7人團隊用5個月自研了版本控制系統Scion，並把整個monorepo遷移過去。10月14日，Meta工程師Rain提出署名爭議，為這場遷移補上另一條討論線。

先看數字的分量。CI每天約2,500萬次checkout，若按Git的全量拉取模式，每天流量會超過600 PB。main分支歷史接近100 GB。這幾個數字放在一起，說明的問題很單純：程式碼生成成本下降一個數量級之後，最先撐不住的是為人類速度設計的下遊基礎設施，版本控制、建構、CI、合併佇列。

Git在哪裡先失效

Git的設計前提是分布式：每個clone都是完整倉庫，可離線算diff、查歷史、跑blame。對多數倉庫，這是正確設計。Anthropic的部落格點出一個關鍵觀察：和多數公司一樣，該公司實際上把Git當中心化系統用，只有一個權威副本；而幾乎所有客戶端都是agent與任務，天然在線。為離線協作設計的特性，在這個場景反而成為擴展阻力。

大倉庫的標準手段，shallow clone、sparse checkout、promisor remote、內部鏡像、blob storage裡的倉庫快照，Anthropic都用過。問題在於合併速度上來之後，快照距main最新提交越來越遠，在部分clone上維持diff與blame正常運作的成本持續上升。換句話說，這些手段只能延緩，不能解決。

Scion的設計帳：把計算集中，換本地資料量下降

Scion基於「客戶端永遠在線」的前提，做了幾項和Git根本不同的取捨。

客戶端與服務端不對稱。Git的每個客戶端都能充當完整服務端；Scion把歷史查詢、blame、commit、merge、rebase全部收歸服務端，客戶端只維持有上限的本地物件快取與工作副本。本地資料量大幅下降，代價是客戶端幾乎沒有獨立計算能力。

所有查詢開放為API。CI任務想查某一行最後由誰修改、兩個提交的關係，不必維護本地倉庫，直接呼叫服務端。部落格特別提到，內部的自動bisect與自動revert流水線，沒有這種低成本的程式化存取無法規模化。

提交必須廉價、增量、無鎖。所有commit、rebase、merge在服務端完成，沒有push。建立提交的成本與變更大小成正比，與倉庫大小無關。Scion還刻意弱化ref，除main與發布分支外基本不用，因為需要所有伺服器達成一致的全域狀態，遲早成為擴展瓶頸。

工作副本可選且預設稀疏。CI任務直接向服務端要某提交與merge base之間的diff，許多寫操作全程不經checkout。

影響推演：誰先撞牆，誰收帳

這次遷移最值得看的面向是瓶頸移動的方向。agent寫程式碼的速度一旦超過某個門檻，工程重心就從「怎麼寫得更快」轉到「怎麼讓下遊接得住」。Anthropic自己估計，6到12個月內這類問題會變得普遍。

受壓的一端是沿用Git中心化託管模式的平臺與大型monorepo團隊。當agent產生的提交量進入每日數萬次量級，託管平臺的頻寬、鏡像成本與合併佇列延遲都會被放大。受惠的一端，短期內是自建版本控制能力的工程團隊與相關基礎設施投資；中期看，這類設計原則若被開源或被平臺商複製，會下沉為託管服務的新功能面。

這與我們先前從採購與合規角度分析的ZCode事件信任成本帳屬於同一條傳導鏈的不同環節：AI編程工具的輸出量放大之後，企業端的工程基礎設施與治理成本都會同步上升，只是這次帳記在版本控制這一欄。同樣的邏輯也呼應了Claude封號帳的風控成本結構，規模放大時，最先被重新計價的往往是基礎層。

收束判斷

7人、5個月、一個monorepo，這筆投入相對於日合併30,000次背後的工程產出，是典型的小資本支出槓桿。可確認的事實是：Git在該規模下確實失效，Scion已完成遷移，設計原則已公開。尚待觀察的是署名爭議的後續，以及這套系統是否會外溢為通用方案。對其他重度使用agent編程的團隊，這篇文章的價值在於提前給出了撞牆的座標：當日合併量向萬次量級逼近時，版本控制會是最先被重新審視的那一層。