原文標題：The bridge to agent-scale Git infrastructure
GitHub 10 月 21 日說明 Git 儲存基礎設施的下一階段改造。過去一年，99.99999% 的 GitHub 儲存庫已開始同時存放在原有資料中心與 Microsoft Azure，剩餘極少數高流量儲存庫因跨區寫入延遲而尚未完成遷移。官方指出，從原有機房到 Azure 目標區域約 1,000 英里，單次網路往返約 25 毫秒；在需要多次往返且整個儲存庫共用寫入鎖的架構下，這會直接限制寫入吞吐量。
GitHub 將遷移分成兩步：先移動資料，再調整儲存架構，避免在流量快速成長時同時更換兩個核心環節。第一份儲存庫副本於 2025 年 8 月進入 Azure 美國中部區域。現階段多數儲存庫具有五份副本，其中兩份在 Azure，Azure 已承接約一半 Git 流量。Spokes 系統會依地理區域與可用區優先將讀取流量導向較近的副本。
目前 Spokes 的寫入法定人數機制雖只需要多數副本確認，卻仍會等待所有健康副本回應或逾時；最慢的副本因此拖慢整體寫入。GitHub 計畫把序列化範圍從整個儲存庫改為個別 Git reference，例如分支與標籤。只有同時更新相同參照的寫入需要互相等待，更新不同分支的開發者或代理可並行提交。GitHub 表示，使用貼近真實流量的內部測試時，不同參照的寫入吞吐量可提升約三至四倍，延遲也更低。
讀取方面，GitHub 說明多數儲存庫每一次寫入對應約 100 至 1,000 次讀取，將讀寫運算與儲存分離可讓兩者各自擴充。新架構會將 Azure Blob Storage 納入寫入法定人數機制，以「虛擬副本」將資料持久化到物件儲存；讀取虛擬副本則可按需求建立，從 Blob Storage 暖機快取而不必參與寫入協調。
GitHub 也坦言仍有待解決的問題：部分讀取需要同步確認參照狀態，而寫入吞吐量仍受法定人數機制限制。Spokes 同時承擔路由、修復、重新平衡等功能，每天處理超過 1,000 億次內部操作；這次改造是分階段落地的架構演進，不等於所有設計已經全面切換。
發生了什麼事
GitHub 正將 Git 儲存庫遷往 Azure，並以每個參照獨立協調及虛擬讀取副本解決跨區延遲與擴充限制。
為什麼重要
AI 代理與開發者可能同時對不同分支大量讀寫，舊式儲存庫全域寫入鎖會讓互不相關的操作彼此等待。
影響哪些人
GitHub 平台使用者、企業大型儲存庫維運團隊，以及關注雲端 Git 儲存架構的工程師，都會受到未來服務擴充能力影響。
已確認與未確認
已確認遷移比例、25 毫秒跨區往返、五副本配置與內測三至四倍吞吐量；新架構仍分階段部署，不能將測試結果視為所有儲存庫現況。
