Git’in Önümüzdeki 10 Yılı İçin Evrimi

• Dünya genelindeki geliştiricilerin kullandığı Git, önümüzdeki 10 yıla hazırlanmak için yapısal değişiklikler yürütüyor; başlıca yenilikler güvenlik, ölçeklenebilirlik ve kullanılabilirlik etrafında şekilleniyor
• En dikkat çekici değişim, SHA-1’den SHA-256’ya geçiş; 2030’a kadar SHA-1 kullanımının yasaklanması planlanıyor, ancak ekosistem desteğinin yetersizliği nedeniyle benimsenme yavaş ilerliyor
• Reftable ile yüz milyonlarca başvuruyu verimli biçimde yönetmek, dosya sistemi kısıtlarını ve eşzamanlılık sorunlarını çözmek için çalışmalar sürüyor
• Büyük dosya işleme yeteneklerini geliştirmek amacıyla Large-object promisors ve takılabilir nesne veritabanı geliştiriliyor; bunlar Git 2.50 sonrası sürümlere kademeli olarak entegre ediliyor
• Jujutsu gibi yükselen sürüm kontrol sistemlerinden etkilenen Git, kullanıcı arayüzünü sadeleştirerek ve yeni komutlar ekleyerek modern iş akışlarını desteklemeyi amaçlıyor

---

Git’te neden değişim gerekiyor?

• Git, 2005’te yayımlandığından beri 20 yıl boyunca milyonlarca depo ve sayısız betiğin bağımlı olduğu temel bir araç haline geldi
  • Ancak SHA-1 güvenlik zafiyetleri, büyük depoların artışı ve CI boru hatlarının yaygınlaşması gibi değişimler, yapısal sınırlarını görünür kıldı
• SHA-1 için çakışma olasılığı, 2017’de CWI ve Google’ın gerçekleştirdiği SHAttered saldırısı ile kanıtlandı
  • GPU hesaplama gücündeki artış nedeniyle büyük kuruluşlar hash çakışmalarını hesaplayabilecek seviyeye ulaştı
• Git’in kökten bir yeniden tasarımdan ziyade kademeli evrimi seçmesi gerekiyor; bu yüzden mevcut ekosistemle uyumluluğu koruyarak değişiyor

SHA-256 geçişi

• Git 2.29’da (Ekim 2020) SHA-256 desteği eklendi, ancak GitHub gibi büyük platformlar hâlâ desteklemiyor
  • Git, Dulwich ve Forgejo tam destek sunarken; GitLab, go-git ve libgit2 deneysel destek aşamasında
• SHA-1 yalnızca basit bütünlük doğrulaması için kullanılıyor gibi görünse de, imzalar, CI ve betikler dahil tüm ekosistem çakışma direncini temel alarak çalışıyor
• Devlet ve şirket düzenlemeleri nedeniyle 2030’a kadar SHA-1’in kaldırılması gerekiyor; Git 3.0’da varsayılanın SHA-256 olması planlanıyor
• Ekosistemin geçişi için kullanıcıların araçlarını test etmesi ve forge desteği talep etmesi öneriliyor

Reftable’ın benimsenmesi

• Mevcut Git, her başvuruyu ayrı dosyada saklayan loose reference yapısını kullanıyor
  • On milyonlarca başvuru içeren depolarda bu yapı verimsiz kalıyor ve dosya sisteminde büyük/küçük harf ayrımı sorunları ile eşzamanlılık tutarsızlıkları doğuruyor
• Reftable, ikili biçim tabanlı bir tablo yapısı sunuyor; bu sayede atomik güncellemeler ve verimli başvuru yönetimi mümkün oluyor
  • GitLab’in 20 milyon başvurulu depo örneğinde, mevcut packed-refs dosyasının yeniden yazımı için 2 GB gerekiyor
• Git 3.0 ile Reftable’ın varsayılan arka uç olması planlanıyor; dosyalara doğrudan erişim yerine Git komutlarının kullanılması tavsiye ediliyor

Büyük dosya işlemenin iyileştirilmesi

• Git metin dosyalarını sıkıştırmada verimli olsa da, ikili dosyalar değiştiğinde tüm nesnenin yeniden oluşturulması nedeniyle verimsizlik ortaya çıkıyor
  • GitLab analizine göre depo alanının %75’i 1 MB üzerindeki ikili dosyalar tarafından kullanılıyor
• Large-object promisors özelliği, büyük nesneleri ayrı bir uzak depoda saklayarak CDN veya S3 API üzerinden aktarılmasını mümkün kılıyor
  • Protokol uygulaması Git 2.50~2.52’de tamamlandı ve istemci tarafında kullanılabilir duruma geldi
• Takılabilir nesne veritabanı, ikili verilere özel depolama biçimi getirerek artımlı saklamayı desteklemeyi hedefliyor
  • Git 2.53’te birleşik nesne veritabanı arayüzü eklendi; 2.54’te bir kavram kanıtı (PoC) bekleniyor

Kullanıcı arayüzü iyileştirmeleri

• Git komutları uzun süredir karmaşık ve tutarsız olmakla eleştiriliyor; Rust tabanlı Jujutsu (JJ) güçlü bir alternatif olarak öne çıkıyor
  • Jujutsu, geçmişin otomatik yeniden yerleştirilmesi, çatışmaların veri olarak ele alınması ve commit’lerin taslak gibi yönetilmesi gibi özellikler sunuyor
• Git, mevcut iş akışlarını bozmadan Jujutsu’nun bazı güçlü yönlerini benimsemeye başladı
  • Git 2.54’te git history split ve git history reword komutlarının eklenmesi planlanıyor
  • İleride daha fazla geçmiş düzenleme alt komutu eklenmesi hedefleniyor
• Steinhardt, Git’in rekabetten öğrenmeye devam ettiğini ve arayüz modernizasyonu ile kullanılabilirlik iyileştirmelerinin sürdüğünü vurguluyor

[GN⁺]

Hacker News yorumları

• Git gerçekten güzel bir yazılım, ama programcı merkezli karmaşıklığını olduğu gibi dışa vuran bir yanı var
  Geliştirici olmayan rollerdeki insanlara Git öğretmeyi denedim, ama onlar özelliklerin ince güçlülüğünden tam anlamıyla yararlanamadı
  Learn Git Branching gibi siteler harika öğrenme kaynakları. Keşke bu tür bir UX, sezgisel varsayılanlar ve kademeli öğrenme akışı gibi unsurlarla Git’in temel deneyimine işlenmiş olsa
  Bugünlerde Claude, Codex, OpenCode gibi agent CLI araçlarıyla bu deneyimi kolayca sunabiliyorsunuz. Ama Git’in kendisi daha erişilebilir bir soyutlama sunsa çok daha kolay olurdu

  • Sorun Git’in karmaşıklığı göstermesi değil; bu karmaşıklığı yanlış terminoloji ve kavramlarla ve berbat dokümantasyonla ifade etmesi

• Git 3.0 için gerçekten heyecanlıyım, ama aynı zamanda hemen hayal kırıklığına uğramaya da hazırım 😅
  jj, Git kullanıcılarına büyük yardım sağladı. Çünkü daha sezgisel bir VCS frontend’inin mümkün olduğunu gösterdi

  • Ne kadar çok rekabet olursa, ekosistem için o kadar iyi bir itki olur

• GitLab’da 2GB’lık bir packed-refs dosyasının birkaç saniyede bir yeniden yazıldığı durumlar gördüm; “bu neden oluyor” gerçekten anlayamıyorum

  • Ve dürüst olmak gerekirse, böyle bir durumda Git’in ya da o kişinin bunu neden umursaması gerektiğini de bilmiyorum

• Büyük dosyaları dışarıda depolamak, merkezi bir modele doğru atılmış bir adım gibi görünüyor ama Git’in ilk tasarım felsefesiyle çelişiyor

  • O kadar da değil. Bu sadece adresleme modeli ve arayüz meselesi. Merkezi bir depo kullanabilirsiniz ama IPFS gibi dağıtık depolamayı da kullanabilirsiniz
  • Evet. Git bir DVCS’dir, genel amaçlı bir DVFS değil. Ben belge depolama için bir DVFS’e ihtiyaç duydum ve kendim bir tane yaptım. Basit, hızlı ve amacına uygun şekilde iyi çalışıyor

• SHA1’den çıkış geçişi fazlasıyla uzun sürüyor
  Hash fonksiyonları en baştan daha modüler bir yapıyla tasarlanmalıydı

• Bence Git’in commit düzeyinde yazılım lisansı takibi özelliğine ihtiyacı var

  • Ne demek istediğini tam anlamadım ama bu Git’in yapacağı iş değil. Git sadece bir kaynak kod yönetim sistemi; ek özelliklerin git-annex gibi genişletme araçlarıyla uygulanması daha doğru
  • Git böyle bir özelliğe sahip olursa daha kötü olur. Commit’lerde zaten keyfi veri saklayabiliyorsunuz; ihtiyaç duyulan metadata’yı doğrudan commit’e koyup ayrı bir araçla işlemek yeterli
  • LLM destekli kodda olduğu gibi trailer kullanabilirsiniz
    Örnek: Co-Authored-By: Whatever LLM, License: WTFPL