GitHub'ın Project Rubicon'u Git depolamasını reference compare-and-swap üzerine yeniden kuruyor, 5.000 agent ile test edildi

GitHub ne duyurdu

Şirketin mühendislik yazısına dayanan bir dev.to derlemesine göre GitHub, 5 Kasım 2026'da yeniden inşa ettiği Git mimarisinin ardındaki depolama tasarımı olan Project Rubicon'u yayımladı. İç testlerde sistem, tek bir depoda çalışan 5,000 eşzamanlı agent'ı yönetirken saniyede 7,200 push ölçüldü. Bu rakamlar sınırlı bir özel önizlemeden geliyor; gelecek yılın başında daha geniş bir yaygınlaşma bekleniyor ve listede altı ek optimizasyon daha var.

Tasarım, Git'in kendisine ait bir özelliğe yaslanıyor: nesneler değişmezdir ve içerik hash'i ile adlandırılır; dolayısıyla iki yazıcı aynı nesneyi koordinasyon kurmadan aynı anda saklayabilir. Bir push'un gerçekten uzlaşı gerektiren tek kısmı reference güncellemesidir — yani bir dalın hangi commit'i işaret ettiğini söyleyen gösterge. GitHub'ın ilan ettiği ilke şudur: reference güncellemeleri konsensüs gerektiren tek şeydir ve bu kayıt, içeriği taşıyan pack ile karşılaştırıldığında çok küçüktür.

Pack'ler reference'lardan ayrılıyor

Rubicon depolamayı iki katmana bölüyor. Pack verisi — sıkıştırılmış Git içeriği — Azure Blob Storage'a giderken, reference durumu GitHub'ın kendi geliştirdiği, çoğaltılmış bir log servisi olan Ref-CAS'ta tutuluyor. Bir push'u ele alan sanal replica gelen pack'i indeksler, önce onu Blob Storage'a yükler ve ancak sonra manifest'te pack'i listeleyen ve reference'ları taşıyan tek bir transaction'ı Ref-CAS'a işler. Bir reference, işaret ettiği nesneler kalıcı hale gelmeden asla commit edilmediği için kurtarma işlemi, mevcut verilere işaretçileri yeniden oynatmaya indirgeniyor.

Veri düzleminin üzerinde, GitHub'ın mevcut yönlendirme, yük dengeleme ve kiracı bölümlendirme katmanı olan Spokes değişmeden kalıyor. Her depo, yerel diskleri salt cache olan ve her an yeniden inşa edilebilen küçük bir sanal replica grubuna eşleniyor. Doğruluk hiçbir zaman hangi replica'nın isteğe hizmet ettiğine bağlı olmadığından GitHub, yoğun bir depoya migration olmadan replica ekleyebiliyor.

Önce başarısız olan iki tasarım

dev.to yazısı, Ref-CAS'ı şekillendiren iki önceki denemeyi belgeliyor. İlki, bir depodaki her reference için write-ahead log tutuyor, tek bir blob ile indeksliyor ve her güncellemeyi o blob'a karşı koşullu olarak yazıyordu. Doğruydu ama bir blob'a aynı anda yalnızca bir koşullu yazım havada olabildiğinden, throughput'u saniyede birkaç yüz yazımın ortasında tıkandı.

İkinci deneme, reference'ları hash'e göre segment blob'larına bölerek farklı segmentlere yapılan yazımların birbirini beklemesini sona erdirdi. Bu, yazım üst sınırını yükseltti ama her okumanın her segmenti kontrol etmesini zorunlu kıldı ve gecikmeyi en yavaş segment belirledi. Yoğun depolarda okumalar yazımlardan birkaç kat fazlaysa, bu takas yanlış yöne gitti.

Ref-CAS üçüncü cevap: fiilen reference durumuna adanmış küçük bir konsensüs grubu. Bir transaction yalnızca dokunduğu reference'ları kilitler, her birinin hâlâ yazıcının beklediği değeri taşıdığını doğrular ve log'un replica'larının çoğunluğu kaydettiğinde görünür olur. Agent'lar çoğunlukla kendi dallarına push ettiğinden, güncellemelerin çoğu paralel olarak çoğaltılır ve çakışmaz.

Okumalar tek bir sürüm kontrolüne mal oluyor

Her Ref-CAS commit'i bir log sequence number taşıyor ve en son commit'in sequence number'ı depo sürümü olarak hizmet ediyor. Bir okuma, replica'nın halihazırda tuttuğu sürümü göndererek başlar; sürüm güncelse yanıt hiçbir reference verisi taşımaz. Değişmemiş bir depo bu nedenle tek bir karşılaştırmaya mal olur — bu önemlidir, çünkü GitHub'a göre bir deponun günlük istekleri Mart ve Mayıs 2026 arasında kabaca 4 kat büyüdü; bunu CI çalışmaları, dağıtım sistemleri ve yeni commit'i çeken diğer agent'lar sürüklüyor ve tasarım, bugünün en yoğun depolarının taşıdığı ölçeğin en az iki kat fazla büyüklük derecesi daha fazlasını planlıyor.

Compaction arka plan düğümlerine taşındı

Her push bir pack ekler ve her ekstra pack aramaları biraz daha pahalılaştırır; dolayısıyla pack sayısı sınırsız büyüyemez. Eski tasarım compaction işini trafiğe hizmet eden replica'larda çalıştırıyordu. Rubicon bu işi, kalıcı depolamayı doğrudan okuyup yazan ve yalnızca bir düğümün bir shard'a dokunmasını Blob Storage'daki lease'ler aracılığıyla koordine eden adanmış arka plan düğümlerine taşıyor. Bir düğüm yeni pack'leri bir segmentte toplar, onu sayı, boyut veya yaş ile belirlenen bir sınırdan mühürler, pack'leri birleştirir ve yüklemeden, manifest'i güncellemeden ve eski pack'leri ikinci bir transaction'la kaldırmadan önce çıktının girdilerle birebir aynı nesneleri içerdiğini kontrol eder. Bu doğrulama adımı tasarımın ağırlığını taşır: tek bir nesneyi düşüren bir pack yayımlamak her replica için okumaları bozar.

Neden önemli

Agentic kodlama iş akışları insan geliştiricilerden çok daha sık push yapar ve her push arkasında okuma amplifikasyonunu sürükler. Rubicon GitHub'ın bu iş yüküne verdiği cevaptır: küçük ve değişebilir parça için konsensüse dayalı bir log, geri kalan her şey için ucuz içerik adresli depolama ve değişmemiş bir depoyu sunmayı neredeyse bedava kılan sürüm kontrollü okumalar. Yayımlanan rakamlar dahili ve önizleme aşamasında; ancak uzlaşıılması gereken ile gerekmeyeni ayırma mimarisi, yüksek frekanslı yazım artı okuma ağırlıklı dağılım yaşayan her sistemin ödünç alabileceği bir desendir.