Ing. Calogero Bono
GitHub, GitHub Universe etkinliğinde duyurduğu yeni Git depolama mimarisi Rubicon'u anlattı. Şirkete göre iç testlerde tek bir depo üzerinde 5.000 eşzamanlı ajana dayanabilmiş, saniyede 7.200 push ve düşük gecikmeli okumalar gerçekleştirilmiş. Bu önemli, çünkü programlama ajanları depoların yükünü değiştiriyor ve bugün GitHub'ın kaldırdığı yük bir yıl içinde yetmeyebilir.
Gerçeklere girmeden önce birkaç terim. Ajan, kod yazıp kendi kendine push yapabilen bir yapay zeka programıdır. Reference, bir dal gibi bir commit'e işaret eden göstericidir. Pack, Git nesnelerini bir araya getiren dosyadır. Compare-and-swap, bir değeri yalnızca başka kimse onu değiştirmediyse güncelleyen bir işlemdir. Blob Storage, Azure'un nesne depolama hizmetidir.
Rubicon nedir ve GitHub onu neden geliştirdi?
Rubicon, GitHub'ın Git verilerini nasıl sakladığını ve sunduğunu yeniden tasarladığı projenin adı. GitHub'ın yazısına göre çalışma, Azure'a ilk geçişin hemen ardından Mayıs 2026'da başladı.
Nedeni yük. GitHub, bugün en yoğun depoların kısa patlamalar halinde en fazla saniyede onlarca yazma aldığını söylüyor. Paralel ve sürekli çalışan ajanlarla bunun bir yıl içinde sabit bir tempoya dönüşmesini bekliyor. Bu yüzden en az iki kat büyüklük sırası ileriye dönük bir hedef koymuş.
GitHub hangi ölçek gereksinimlerini belirledi?
GitHub iki eksen ayırıyor. Yatay ölçek çok sayıda depoyla ilgili ve burada bölümleme ile yüke göre yönlendirme gibi denenmiş çözümler geçerli kalıyor. Dikey ölçek ise tek ve çok büyük, yoğun bir depoyla ilgili ve neredeyse tüm gereksinimler buradan geliyor.
Tek bir depo için mimari, saniyede binlerce yazmayı kaldırmalı ve birden fazla yazma düğümünü desteklemeli. Ayrıca bir ajan bir sonraki adıma geçmeden önce her push'u beklediği için commit gecikmesini de düşürmeli. Her push ayrıca CI, dağıtım ve diğer ajanlardan gelen daha fazla okuma üretiyor ve GitHub güçlü bir çoğaltma etkisinden söz ediyor.
Örnek olarak, günlük trafiği Mart ile Mayıs arasında yaklaşık 4 kat artan bir depo veriliyor.
Yeni mimari nasıl çalışıyor?
Temel fikir, yalnızca reference güncellemeleri üzerinde uzlaşma gerektiği. Git nesneleri değişmez ve içeriğine göre tanımlanır, bu yüzden birden fazla yazıcı bunları birlikte kaydedebilir. Böylece depolama, istek sunumu ve bakım bağımsız ölçeklenir.
İstekler, yönlendirme ve yük dengelemesini sürdüren Spokes'a ulaşır. Altında, sanal kopyalar, yerel diski yalnızca yeniden oluşturulabilir bir önbellek olan geçici hesaplama içeren yeni bir veri düzlemi var. Kalıcı durum iki yerde tutuluyor.
- Pack dosyaları ve hızlandırma verileri Azure Blob Storage'da.
- Reference'lar ve pack listesi (manifest) çoğaltılmış bir log hizmeti olan Ref-CAS'ta.
Bir yazma, pack dosyasını indeksler, Blob Storage'a yükler ve Ref-CAS'ta tek bir işlem yapar. Bir okuma, reference sürümünü kontrol eder, eksik pack dosyalarını indirir ve önbellekten yanıt verir. Pack sıkıştırma, kopyalarda değil ayrı düğümlerde çalışır.
Git'i her gün kullananlar için bir şey değişiyor mu?
GitHub'a göre hayır. Git Git olarak kalıyor, push, fetch ve dallar aynı şekilde ve aynı korumalarla çalışıyor. Değişiklik perde arkasında ve platform çalışmaya devam ederken hayata geçiriliyor.
Konu, OpenAI'ın Pierre'i satın alması gibi ajanlar için Git araçlarındaki gelişmelerle bağlantılı. Temel komutları iyi bilenler, örneğin Git bisect ve blame ile, alışkanlıklarını değiştirmek zorunda kalmıyor.
Bilmen gereken sınırlar
5.000 ajan ve saniyede 7.200 push rakamları, GitHub'ın bildirdiği iç testlerden geliyor ve dış bir doğrulamaya sahip değil. Sağlanan metin, incelenen iki bileşenin ayrıntılarından önce kesiliyor, bu yüzden teknik ödünleşimleri bilmiyoruz. Tüm depolar için tam bir benimseme tarihi de görünmüyor.
Dijitalle çalışanlar için ne değişiyor
Bir ajans ya da küçük bir ekip için kısa vadede neredeyse hiçbir şey değişmiyor. Asıl nokta başka. Akışlarında çok push yapan ajanlar kullanıyorsan, GitHub bunların dayanabilmesi için hazırlanıyor. Yine de her push zincirleme okumalar üretir, bunu GitLab CI/CD ile GitHub Actions karşılaştırması da anlatıyor, bu yüzden kendi boru hattını düşünmek faydalı. Çok sayıda müşteriye hizmet veren platformlar ise hesaplama ile veriyi ayırma ilkesine bakabilir, bu da çok kiracılı mimariye yakın bir konu.
Bizim görüşümüz
Rubicon ciddi bir mühendislik projesi ve yalnızca referansları koordine etme fikri zarif. Ama adın da bir mesaj veriyor. GitHub, ajan yükünü geri dönüşü olmayan bir nokta olarak görüyor ve bunu kesin kabul ediyor. Büyümenin öngörüldüğü gibi gerçekleşip gerçekleşmeyeceği ve sentetik testlerin gerçek kullanımı abartıp abartmadığı henüz belli değil. Sağlayıcının kendi verileri yerine bağımsız verilere ihtiyaç var.
Sıkça sorulan sorular
GitHub'ın Project Rubicon'u nedir?
GitHub Universe'de duyurulan, GitHub'ın yeni Git depolama mimarisidir. Depolamayı ve hesaplamayı ayırır ve yalnızca reference güncellemelerini koordine eder.
Saniyede kaç push kaldırabiliyor?
GitHub, iç testlerde 5.000 eşzamanlı ajanla bir depo üzerinde saniyede 7.200 push rakamını bildiriyor. Bunlar şirketin verileri, üçüncü taraflarca doğrulanmadı.
Git kullanma şeklimi değiştirmem gerekir mi?
Hayır. GitHub'a göre push, fetch ve dal işlemleri aynı korumalarla eskisi gibi çalışıyor.
Veriler nerede saklanıyor?
Pack dosyaları Azure Blob Storage'da duruyor. Reference'lar ve pack listesi ise çoğaltılmış bir log hizmeti olan Ref-CAS'ta tutuluyor.
Bir depo için neden birden fazla kopya gerekiyor?
Pack dosyalarını indekslemek ve nesnelerin bağlantısını kontrol etmek çok CPU tüketiyor. Birden fazla düğüm işi dağıtır ve hataya dayanıklılığı artırır.
Rubicon herkesin deposuna ulaştığında nelere bakmalı
Asıl sınav, iç sayılardan gerçek depolara geçiş olacak. Dikkat etmen gerekenler şunlar.
- Ödünleşimleri anlamak için GitHub'ın iki ayrıntılı bileşen hakkındaki sonraki yazı dizisini takip et.
- Önümüzdeki aylarda kendi depolarının push ve fetch sürelerinin değişip değişmediğini kontrol et.
- GitHub'ın çok sayıda paralel push yapan ajanlar için limit ya da kullanım kuralları yayımlayıp yayımlamadığına bak.
