GitHub 於二〇二六年十月二十一日刊出工程博客，說明為「代理規模」重建 Git 儲存的過渡方案：平台已把百分之九十九點九九九九九的倉庫副本雙寫至 Azure，並改以單一 Git 參照（reference）為單位做法定人數寫入序列化；內部測試指不同參照並發寫入吞吐約可提升三至四倍。來源真實性已驗證。

GitHub／官方：為代理規模重建 Git 基建——百分之九十九點九九九九九倉庫已雙寫 Azure；單一參照法定人數內部測試寫入吞吐約三至四倍

GitHub 於二〇二六年十月二十一日在官方工程博客〈The bridge to agent-scale Git infrastructure〉公布，過去一年在 Git 流量指數增長下，平台已把百分之九十九點九九九九九的倉庫同時放在自有數據中心與 Azure；餘下約十萬分之一屬最繁忙倉庫，正受跨區約二十五毫秒往返延遲與「整庫寫鎖」吞吐上限卡住。本文已核對 GitHub Blog 原文時間戳與論述數字；來源真實性已驗證。下文整理遷移現況、為何代理流量逼出架構橋接、單一參照法定人數與物件儲存虛擬副本的技術含義，以及對香港與亞洲企業雲端／AI 開發的啓示。

一、核心事件：幾乎全部倉庫已雙寫，卡關的是最忙的那十萬分之一

技術細節

官方把今次文章定位為「舊設計與新設計之間的即時橋樑」：在不完全一次換成最終雲原生儲存架構的前提下，先把數據與依賴遷到 Azure，並改寫法定人數（quorum）的序列化範圍，讓最繁忙倉庫也能跟上。文中交代的可核對要點包括：

雙寫覆蓋率：百分之九十九點九九九九九的 Git 倉庫已同時存在於 GitHub 自有數據中心與 Azure；其餘約 百分之零點零零零零一 屬平台最繁忙倉庫。
遷移進度：二〇二五年八月，首個倉庫副本落地 Azure Central US；至今多數倉庫的五個副本中已有兩個在 Azure，Azure 約承擔一半 Git 流量，並在自有機房負載大致持平的情況下吸收增量。
驅動因素：官方明言節奏由「代理式（agentic）轉型」帶動——流量急升、自有機房與周邊地區電力容量見頂，以及實體供應鏈限制；剩餘擴容窗口夠安全遷移，但不足以慢慢來。
卡點物理距離：目標 Azure 區域與自有機房相距約一千英里，跨區網絡往返約 二十五毫秒；寫入需多趟往返時，最慢的健康副本會拖高每一次寫入延遲。
現行 Spokes 法定人數：提交寫入只需多數同意，但會等待每個健康副本回應（直至逾時）；再加上整庫範圍寫鎖，等於單一佇列一次只能飛一筆寫入，吞吐上限由最慢副本決定。
橋接改動——單一參照序列化：把法定人數序列化範圍由「整個倉庫」改為「個別 Git reference」（例如不同分支）。代理與開發者推送到不同分支時不再互相排隊；官方指內部以真實流量測試，不同參照並發寫入吞吐穩定見約三至四倍、且延遲更低。
讀寫分離方向：多數倉庫讀寫比約在一百至一千比一；下一步把 Azure Blob Storage 納入法定人數作為「虛擬寫入副本」（完全無狀態／短暫計算節點），寫入須耐久落盤才確認，再按需擴出虛擬讀取副本自 Blob 暖機快取、不加入寫入法定人數。內部負載架在舊架構常先撞天花板；對虛擬讀取副本測試時，反而是測試架本身先達上限。
營運量級：Spokes 除協調法定人數外，亦是路由、負載平衡與統一內部 API，官方稱每日處理遠超一千億次倉庫數據操作；並指「撐起十億倉庫」的提交協定，不足以走到「下一個十億」。完整寫入重構與 GitHub Universe（二〇二六年十月二十八至二十九日）後續文預告另文再述。

Git 被列為 Tier 0 服務：幾乎所有 GitHub 功能依賴倉庫數據，因此必須先搬數據、服務與依賴。流量跟隨數據遷移；Spokes 優先把請求導向與請求相同區域／可用區的副本，直至舊區不再接收請求。

二、技術原理深度解析

為何「已經上雲副本」仍不夠。 多區存放提高耐久與就近讀取，但若寫入路徑仍以整庫鎖串行，並在每次提交等待跨區最慢副本，忙碌倉庫會在遷移過程中先被自己的一致性協定卡住。二十五毫秒級往返在單次人機推送或可接受，但在代理連續開分支、推送、更新多參照的高並發下會迅速堆成佇列。

單一參照法定人數 = 只序列化真正衝突的寫入。 Git 的一致性要求本質上落在各 reference 的更新次序；物件本身以內容定址且不可變，多數「不同分支」的寫入並不需要互相等候。把鎖從倉庫級降到參照級，等於把單線佇列改成可按分支並行的多線道——這正是代理批量開工作分支時最需要的頭寸。

物件儲存虛擬副本 = 耐久與讀擴容解耦。 當 Blob 成為法定人數成員後，寫入確認綁定物件儲存耐久；讀取副本可短暫、可水平擴，並以物件儲存為真相來源在背景對帳。讀多寫少的負載從此不必跟寫入副本搶同一份記憶體與壓縮（compaction）資源。官方亦提到虛擬寫入副本可把不相交參照的交易合併成一組網絡 I/O，讓繁忙倉庫用「一趟往返」攤提多筆並發寫入。

對企業的通用含義。 這不是行銷向的「AI 功能上架」，而是把代理流量當成一級容量規劃假設：電力、跨區延遲、鎖粒度、讀寫能否獨立擴容，全部要重算。自建 Git／制品庫或混合雲的團隊，可對照自身是否仍用「整庫鎖 + 同構讀寫節點」硬扛 CI 與編碼代理。

四、日常應用場景

1. 開發者與技術團隊

若團隊已讓編碼代理大量開分支、並行提交，應監測「寫入佇列長度／P99 推送延遲／跨區副本落後」，並檢視鎖是否過粗。評估雲端 Git 或制品服務時，可要求供應商說明法定人數範圍、物件儲存是否進入寫入確認路徑，以及讀副本能否與寫入解耦擴容。

2. 企業與隱私敏感行業

金融、政府與醫療若把源碼留在指定司法管轄區，雙寫／多副本遷移同樣撞上電力、機架與跨區延遲。可借鑒 GitHub 的「先搬 Tier 0 數據與依賴、再用協定改動釋放最忙十分位」節奏，避免在流量高峰期同時換平台又換一致性協定。香港機構若走私有雲或在港託管，亦應把代理流量納入容量與異地備援演練，而非只按人力開發者峰值估算。

3. 一般用戶

一般 GitHub 使用者短期感受可能是繁忙開源倉庫在高峰推送更穩、代理工具較不易因基建排隊失敗。真正的產品承諾仍以平台狀態頁與各倉庫設定為準；本文焦點是官方公開的架構橋接，而非單一消費者功能開關。

4. 香港與亞洲市場視角

亞洲企業正把 Copilot／編碼代理／CI 機器人接入大型單一倉庫（monorepo）與大量微服務倉庫，Git 操作會由「人為尖峰」變成「全日機器尖峰」。GitHub 以可核對百分比與內部三至四倍寫入測試，說明雲端遷移不能只搬磁碟，還要改並發控制與讀寫拓樸。對香港雲端遷移項目，可把「代理流量假設、跨區 RTT、鎖粒度、物件儲存耐久確認」寫進驗收清單；若同時要在可控環境跑私有模型服務代理，亦需一併規劃與源碼區網的延遲與權限邊界。

五、專業評價與潛在考量

優勢

一級工程來源：GitHub 官方博客給出遷移覆蓋率、副本佈局、跨區延遲、內部吞吐倍率與每日操作量級。
問題設定清楚：點名代理流量、電力天花板與整庫鎖，而非空泛「上雲」。
改動可解釋：單一參照序列化直接對應 Git 資料模型；虛擬副本路徑說明如何把讀擴容從寫入法定人數拆出。
系列可追溯：與二〇二六年十月六日〈Building Git infrastructure for agent-scale development〉原則文銜接，今次屬橋接實作。

需要留意的地方

三至四倍為內部測試：屬官方自述 realistic traffic 結果，不等於你方倉庫保證倍率；跨區拓樸與參照衝突模式會改變效果。
最終寫入架構尚未完成：文末承認提交協定仍須再演進才能支撑「下一個十億倉庫」，Universe 後續文才披露端態。
雙寫並非主權／合規答案：副本進 Azure 中央美國區，對數據駐留有要求的客戶仍須看企業合約與獨立產品選項。
餘下十萬分之一才是壓力測試：大多數倉庫已雙寫，不代表最忙 monorepo／熱門開源庫已走完同一路徑。

結語

GitHub 這篇橋接文把「代理規模」從口號落成可核對的基建帳：百分之九十九點九九九九九倉庫已雙寫 Azure，卡關的是跨區延遲加上整庫寫鎖；單一參照法定人數與物件儲存虛擬副本，正是為機器並發推送預留吞吐與讀擴容。對香港讀者與技術決策者而言，重點不是品牌雲選邊，而是把編碼代理當成一級流量來源，重算鎖粒度、跨區 RTT 與讀寫能否獨立擴。若機構正規劃源碼／制品庫上雲、異地備援或零信任接達，可參閱 YSK Limited 的香港雲端遷移與網絡安全服務；若同時要為內部編碼或營運代理提供數據留港的私有模型環境，亦可了解香港私有 LLM 託管（企業私有 LLM 全託管年費由 HK$88,000 起）。

參考來源