GitHub'ın Project Rubicon'u, binlerce eşzamanlı AI ajan push'u için Git depolamayı yeniden inşa ediyor

Binlerce ajan için tasarlanmış bir Git depolama katmanı

GitHub, GitHub Universe'te duyurduğu yeniden inşa edilmiş Git depolama mimarisinin ayrıntılarını yayımladı ve öne çıkan rakamlar doğrudan AI odaklı geliştirmeye işaret ediyor. GitHub Blog'a göre dahili testler, sistemin tek bir repository üzerinde çalışan 5.000 eşzamanlı ajanı desteklediğini ve bu repository'ye saniyede 7.200 push'u karşıladığını gösterirken, okuma trafiği de tutarlı biçimde düşük gecikmeyle hizmet vermeye devam etti.

Şirket bu tasarımı Project Rubicon olarak adlandırıyor; GitHub'a göre bu isim seçildi çünkü ajan odaklı geliştirme, sektörün çoktan aştığı bir eşik. Çalışmalar Mayıs 2026'da, GitHub depolarının %99,99999'unu Azure'a taşındıktan kısa süre sonra başladı ve yeni katman, platform çalışmaya devam ederken altına inşa edildi. GitHub bunu, yüz milyonlarca geliştiricinin ajan odaklı geliştirmesini desteklemenin temeli olarak konumlandırıyor. Kullanıcılar için arayüzde hiçbir şey değişmiyor: push, fetch ve branch'ler aynı şekilde davranıyor ve aynı korumalar yerinde duruyor.

Ajan trafiği, yoğun bir repository'nin görünümünü değiştiriyor

GitHub, ölçeği iki eksen üzerinden düşündüğünü söylüyor. Birçok repository'de birçok geliştirici ve ajan anlamına gelen yatay ölçek, tenant partitioning, trafik adaleti uygulaması ve yük farkındalı yönlendirme gibi sınanmış tekniklerle zaten karşılanıyor ve bunların hepsi korunuyor. Tek bir repository'de çok sayıda yazıcı anlamına gelen dikey ölçek ise ajanların tabloyu değiştirdiği yer ve yeni gereksinimlerin çoğu bu eksenden geldi.

Bugün GitHub.com'daki en yoğun repository'ler saniyede en fazla onlarca yazma alıyor ve bunlar da genellikle yalnızca kısa patlamalar halinde. GitHub, paralel ve gün boyu süren ajan çalışmalarının bu patlamaları önümüzdeki yıl içinde sürekli bir orana dönüştürmesini bekliyor. Her push ayrıca okumalar olarak da katlanıyor: CI sistemleri yeni commit'e karşı çalışıyor, dağıtım araçları onu çekiyor ve diğer ajanlar bağlam için onu fetch ediyor. Gönderiye göre, tek bir repository'ye yapılan günlük istekler Mart-Mayıs arasında kabaca dört kat arttı ve o zamandan beri üstel biçimde yükselmeye devam ediyor.

GitHub, bir sonraki artışı planlamak yerine en az iki büyüklük mertebesi daha fazla ölçek hedefi belirledi. Bu, somut gereksinimlere dönüştü: tek bir repository'de saniyede binlerce yazma; gelen pack'leri indeksleme ve nesne bağlantısını denetleme bir yazmanın en çok CPU tüketen bölümleri olduğu ve tek bir düğümün hızla işlem gücüyle sınırlı hale geldiği için birden çok yazıcı düğümü; bir ajan sonraki adımını atmadan önce her push'u beklediğinden en düşük commit gecikmesi; referans başına sıralı değişiklikler ve referanslar arasında hızlı doğrusallaştırma; değişiklik olmadığında — ki yaygın durum budur — düşük maliyetli okumalar; ve bağımsız olarak ölçeklenen bileşenler.

Yalnızca referans güncellemelerinde koordinasyon

Mimari, GitHub'ın seride daha önce ortaya koyduğu bir gözleme dayanıyor: bir push'un çok küçük bir bölümünün gerçekten sıralanması gerekiyor. Git nesneleri değiştirilemez ve içeriklerine göre adlandırılır, dolayısıyla iki yazıcı hiçbir konuda anlaşmadan nesneleri aynı anda saklayabilir. Anlaşma gerektiren tek bölüm, karşılaştırıldığında çok küçük olan referans güncellemesidir. Bundan iki ilke çıkar: koordinasyonu en aza indir ve depolamayı işlem gücünden ayır.

Rubicon'un içinde: sanal replikalar, Blob Storage ve Ref-CAS

Kenarda pek bir şey değişmiyor. Spokes hâlâ yönlendirmeyi, yük dengelemeyi, GitHub'ın geri kalanının repository verilerini okuyup yazmak için kullandığı dahili API'yi ve tenant yerleştirme ile adaleti yönetiyor. Spokes'un altındaki veri düzlemi yeni olan şey.

Spokes her isteği, bir repository'ye atanmış küçük bir sanal replika grubundan birine yönlendiriyor. Sanal replikalar okuma, yazma veya her ikisini hizmete sunan, atılabilir işlem gücüdür ve yerel diskleri yalnızca her an yeniden inşa edilebilen bir önbellektir. Yönlendirme önbellekleri sıcak tutmak için aynı replikaları tercih eder, ancak doğruluk hangi replikanın isteğe hizmet verdiğine bağlı değildir ve yoğun repository'ler basitçe daha fazla replika alır. Ayrı bir sıkıştırma düğümü filosu pack'leri arka planda birleştirir ve erişilemez nesneleri kaldırır — asla bir replika üzerinde yapmaz — böylece replikanın CPU'su ve belleği isteklere hizmet vermeye ayrılmış kalır.

Kalıcı durum iki yerde yaşıyor. Okuma hızlandırma verileriyle birlikte pack olarak saklanan Git nesneleri Azure Blob Storage'da durur. Referanslar ve bir repository'yi oluşturan pack'lerin listesi olan pack manifesti ise Reference Compare-and-Swap'dan adını alan replikalı log servisi Ref-CAS'ta yaşar.

Bir yazma iki adımlıdır: sanal replika gelen pack'i indeksler ve Blob Storage'a yükler, ardından pack'i manifest'te listeleyen ve referansları güncelleyen tek bir transaction'ı Ref-CAS'a commit eder. Bir okumada replika, referans sürümünü Ref-CAS ile denetler, ihtiyaç duyduğu pack'leri Blob Storage'dan önbelleğine çeker ve oradan hizmet verir. Sıkıştırma düğümleri daha sonra pack'leri birleştirir, böylece okumalar hızlı kalır.

Neden önemli

Barındırılan Git tarihsel olarak insan ritmine göre boyutlandırıldı: patlamalar halinde saniyede onlarca yazma. Ajanlar kodu gün boyu paralel yazmaya devam ederse, darboğaz genel fil değil tek bir yoğun repository olur ve GitHub depolamasını tam da o dünya için yeniden mimarileştirdi. Tasarım, eşzamanlılığın artık büyük ölçüde makine üretimi olduğunu ve push'ların okumalar olarak katlandığını da kabul ediyor; bu, CI sistemleri veya bu repository'leri tüketen mirror'lar işleten herkes için önemli. Geliştiriciler için en dikkat çekici yanı ise değişikliğin görünmez olması amaçlanması: Git Git olarak kalırken, altındaki taban iki büyüklük mertebesi daha fazla büyüme payı kazanıyor.