GitHub, agent commitleri bir yılda beş kat artınca Git altyapısını canlı olarak yeniden inşa ediyor

Neler oluyor

GitHub, tüm platformunun altında yer alan Git altyapısını yeniden inşa etmeye başladı ve bunu servis canlı trafiğe hizmet vermeye devam ederken yapıyor. GitHub Blog'da yayımlanan bir mühendislik yazısında şirket, projeyi agent destekli yazılım geliştirmeye bir yanıt olarak konumlandırıyor: Günümüzde insan mühendislerin ve yapay zeka agentlarının karışımından günde milyonlarca commit alan repository'ler, yalnızca ara sıra yaşanan yoğunluklara değil, sürekli eşzamanlı okuma ve yazmaya uygun bir depolama ve koordinasyon katmanına ihtiyaç duyuyor.

Bu değişimin ardındaki sayılar

GitHub Blog'a göre platformdaki toplam Git etkinliği Eylül 2025 ile Ağustos 2026 arasında ikiye katlanarak aylık 218,2 milyar olaydan 473,3 milyar olaya yükseldi. Yalnızca Eylül 2026'da geliştiriciler ve agentlar 7,38 milyar commit yaptı; bu, bir yıl önceseki rakamın beş katından fazla. Push hacmi yıl üzerinden 4,9 kat artarak aylık 0,69 milyardan 3,35 milyara çıktı, pull request birleştirmeleri bir yıl önceski seviyeye yakın dört katına ulaştı ve GitHub Actions Eylül'de 3,26 milyar kez çalıştı; bu da önceki yılın dört katından fazla.

Bu yükün dağılımı heavily çarpık. En yoğun tek repository Ağustos 2026'da kabaca bir milyar istek işledi ve GitHub, eğrinin tepesini, aynı kod tabanında çalışan yoğun CI pipeline'larını yürüten büyük mühendislik ekipleri ile büyüyen agent filolarının bir arada olduğu şekilde tanımlıyor.

Neden agentlar mevcut tasarımı zorluyor

Yazı, agent iş yüklerinin insan iş yüklerinden ayrıldığı birkaç noktayı tespit ediyor:

• Commit gecikmesi agent başına bir darboğaz haline geliyor. Sıkı bir döngüde çalışan bir agent neredeyse her işlemden sonra commit veya checkpoint yapıyor, bu yüzden verimi tek bir push'un ne kadar hızlı tamamlandığıyla sınırlı — bir insanın önemsemeyeceği gecikmeler bağlayıcı kısıt haline geliyor.
• Yazma hacmi katbekat artıyor ve tek bir repository'de ayrı branch'lere push yapan binlerce agent, mimarideki tek bir noktaya doğru birikiyor.
• Birleştirmeler tek bir reference üzerinde yığılıyor, çünkü trunk-based development, release train'ler ve merge queue'ların tümü aynı ref'te birleşiyor.
• Her push bir okuma yayılımını tetikliyor; CI ve kod taraması aynı branch ucunu dakikada binlerce kez clone veya fetch ediyor.
• Repository verilerini sıkıştırma ve kullanılmayan nesneleri garbage-collect etme gibi arka plan işleri, yazma hacmi arttıkça birikiyor.

GitHub, okumaların cache ve replica'larla görece kolay ölçeklendirilebildiğini, yazmaların ise daha zor olduğunu belirtiyor: Her push'un dayanıklı biçimde saklanması ve bir sonraki agent ya da CI işi üzerine inşa edebilmeden önce tutarlı biçimde görünür olması gerekiyor.

Mevcut mimari nerede tavana çarpıyor

Bugün her repository Spokes tarafından saklanıyor; Spokes, birkaç fileserver'ın — varsayılan olarak beş tanesinin — yerel disklerinde tam bir kopya tutuyor. Yerel diskler Git'e yerel repository verisine düşük gecikmeli erişim sağlıyor, kopyalar yedeklilik sunuyor ve quorum'lu üç aşamalı commit protokolü CI'nin, web arayüzünün ve API istemcilerinin tümünün tutarlı bir repository durumu görmesini garanti ediyor. GitHub bu tasarımın kabaca bir milyar repository'ye hizmet verdiğini söylüyor.

Sorun, dayanıklılığın ve ölçeğin aynı mekanizmaya dayanması. Diskteki kopyalar doğruluğun kaynağı olduğu için okuma kapasitesi eklemek başka bir dayanıklı replica eklemek anlamına geliyor ve her replica her yazmaya katıldığından bir push, yalnızca kümesindeki en yavaş replica kadar hızlı tamamlanıyor. En yüksek etkinlik seviyelerinde bu sert bir sınıra dönüşüyor: okuma replica'ları yazmaları yavaşlatıyor, bir replica kaybı okuma kapasitesini düşürüyor ve quorum kaybı yazmaları tamamen durduruyor. Yeniden inşanın ifade edilen hedefi, dayanıklılığı ve ölçeği ayrı mekanizmalara bölmek.

Yeniden inşanın kısıtları

GitHub, bu geçiş için bakım penceresi olmadığını vurguluyor — iş, dünyanın repository'leri aktif kalırken ve kullanıcılardan yazılım geliştirme biçimlerini değiştirmeleri istenmeden yürütülüyor. Yeni mimari ayrıca ekiplerin halihazırda kullandığı kontrolleri korumak zorunda: maintainers için branch korumaları ve zorunlu incelemeler, güvenlik ekipleri için audit log'ları ve görünürlük ayarları, nöbetçi mühendisler için güvenilir otomasyon ve gözlemlenebilirlik.

Şirket üç temel ilke ortaya koyuyor: geliştiricilerin halihazırda güvendiği branching, review ve merge gibi iş akışlarının üzerine inşa etmek; her kararı güvenilirliğe karşı ölçmek; ve insanları kodlarının kontrolünde tutmak, agentların ürettiğini inceleyip onaylayabilme yeteneğini korumak. Yazıya göre yaklaşım, agent ölçeğindeki eşzamanlılığa uygulanmış temel dağıtık sistem tasarım ilkelerine dayanıyor; ancak ayrıntılı teknik tasarım yayımlanan metinde tam olarak açıklanmamış.

Neden önemli

Yazı, yapay zeka agent'larının platform gereksinimlerini nasıl yeniden şekillendirdiğinin net bir sinyali: GitHub, agent iş yüklerini bir niş kullanım senaryosu değil, yeni nesil depolama katmanının birincil tasarım kısıtı olarak ele alıyor. Alıntıladığı büyüme rakamları, yazma ağırlıklı ve yüksek eşzamanlılıklı repository'lerin istisnai değil sıradan hale gelebileceğini gösteriyor.

Agent araçları geliştiren ekipler için bahse konu olan şey pratik — bir agent'ın döngüsü push gecikmesi ve merge çekişmesiyle sınırlı, dolayısıyla altyapı iyileştirmeleri doğrudan daha hızlı otonom iş akışlarına dönüşüyor. Ve GitHub bu işi tüm kullanıcılar için taban seviyeyi yükseltmek olarak çerçecelediğinden, kesintisiz geçiş sorunsuz ilerlerse küçük açık kaynak projeleri de binlerce agent çalıştıran kurumlar kadar hızlı ve dayanıklı aynı temeli miras almalı. GitHub'ın dayanıklılığı okuma ölçeğinden tam olarak nasıl ayıracağı ve hangi maliyetle ayıracağı, yazının yanıtını açık bıraktığı teknik soru.