Git’te büyük dosyaların geleceği yine Git’in kendisi

• Git projesi kısa süre önce büyük dosya yönetimi sorununu doğrudan çözmeye resmen başladı
• Git LFS, kullanıcılar için çeşitli maliyetler ve vendor lock-in gibi sorunlar yaratan geçici bir çözüm
• Son dönemde gelen partial clone özelliği sayesinde, yalnızca Git kullanarak LFS’nin rolünün büyük kısmını ikame etmek mümkün hale geldi
• İleride large object promisor adlı yeni bir çözümün de resmi Git’e entegre edilmesi hazırlanıyor
• Bu değişimlerle birlikte, büyük dosya yönetiminin nihai çözümünün harici eklentiler değil, Git’in kendisi olması bekleniyor

---

Git’in büyük dosya sorunu ve değişim

• Git’in en büyük düşmanı tam da büyük dosyalar olabilir
• Büyük dosyalar Git deposunu şişirir, git clone hızını düşürür ve çoğu hosting ortamını da olumsuz etkiler

Git LFS’nin ortaya çıkışı ve sınırları

• 2015’te GitHub, büyük dosya sorununu aşmak için Git LFS’yi yayınladı
• Ancak Git LFS de kendi başına yeni karmaşıklık ve ek depolama maliyetleri getirir

• Git topluluğu uzun süredir büyük dosya sorununu kökten nasıl çözeceğini sessizce düşünüyordu; son resmi Git sürümlerinde ise LFS olmadan büyük dosyaları yönetmeye yönelik yeni bir yön ortaya kondu

Bugün hemen uygulanabilecek yöntem: Git LFS’yi partial clone ile değiştirmek

• partial clone’un çalışma mantığı

  • Git LFS: Büyük dosyalar depo dışında tutulur ve çalışma sırasında yalnızca gerekli dosyalar indirilir
  • Git partial clone (2017’de eklendi):
    • --filter seçeneğiyle belirli boyutun üzerindeki blob’lar hariç tutularak kopyalama yapılır
    • Yalnızca gerektiğinde ilgili büyük dosya sunucudan indirilir
      > Partial clone kullanıldığında Clone ve Fetch sırasında [büyük ikili varlıkları] önceden indirmek gerekmez; bu da indirme süresini ve disk kullanımını azaltabilir
      > - Partial Clone Design Notes, git-scm.com

• partial clone ile LFS’nin ortak yönleri

  • 1. Checkout boyutunu en aza indirme: Yalnızca en güncel sürüm alınır, tüm dosya geçmişi atlanır
  • 2. Hızlı klonlama: Büyük dosyalar aktarılmadığı için clone daha hızlıdır
  • 3. Hızlı kurulum: shallow clone’dan farklı olarak tüm proje geçmişine erişim mümkündür

• partial clone kullanım örneği

  • Geçmişinde çok sayıda büyük PNG dosyası bulunan bir repo’nun klonlama süresi ve disk kullanımı örneği:
    • Normal clone ile neredeyse 4 dakika sürüyor ve 1.3GB yer kaplıyor
    • partial clone ve 100KB blob sınırı uygulandığında 6 saniyede klonlanıyor ve 49MB yer kaplıyor
    • Orijinale göre klonlama hızı %97 iyileşiyor, checkout boyutu %96 küçülüyor

• partial clone’un sınırları

  • Filtrelenen veriye ihtiyaç duyulduğunda (ör. git diff, git blame, git checkout) Git sunucudan dosyayı ister
  • Bu, Git LFS ile aynı özelliktir
  • Pratikte ikili dosyalarda blame çalıştırma ihtiyacı nadirdir

Git LFS’nin sorunları

• Yüksek vendor lock-in: GitHub uygulaması yalnızca kendi sunucularını destekler; bu da ücretlendirme ve bağımlılık yaratır
• Maliyet sorunu: 50GB depolamada GitHub LFS yıllık $40, Amazon S3 ise $13
• Geri dönüşün zorluğu: Bir kez LFS’ye geçildiğinde, geçmiş yeniden yazılmadan eski hâle dönmek mümkün değildir
• Sürekli kurulum maliyeti: Tüm ekip üyelerinin LFS kurması gerekir; kurulmadığında dosya yerine metadata dosyaları görülür ve bu da kafa karışıklığı yaratır

İleriye dönük görünüm: Large Object Promisor

• Büyük dosyalar hosting platformları (GitHub, GitLab) için de maliyet sorunu yaratır
• Git LFS, büyük dosyaları CDN’e offload ederek sunucu maliyetlerini azaltır

• Large Object Promisor nedir?

  • Git bu yılın başında large object promisor adlı özelliği resmen merge etti
  • Bu özellik, LFS’ye benzer şekilde sunucu tarafındaki depo yükünü azaltırken kullanıcı tarafındaki karmaşıklığı büyük ölçüde düşürür
    > Bu çabanın amacı, özellikle zaten ikili biçimde sıkıştırılmış büyük blob’larla ilgili sunucu tarafı işlemlerini iyileştirmektir
    > Git LFS’ye alternatif bir çözümdür
    > – Large Object Promisors, git-scm.com

• Nasıl çalışır?

  • 1. Kullanıcı büyük dosyayı Git host’una push eder
  • 2. Host, büyük dosyayı arka uçtaki promisor’a offload eder
  • 3. clone sırasında Git host’u istemciye promisor bilgisini verir
  • 4. İstemci gerekirse ilgili promisor’dan büyük dosyayı otomatik olarak alır

• Güncel durum ve zorluklar

  • Büyük nesne promisor’u hâlâ geliştirme aşamasında; Mart 2025’te kodun bir kısmı Git’e merge edildi
  • GitLab gibi platformlarda ek implementasyonlar ve çözülmemiş konular üzerine tartışmalar sürüyor
  • Yaygın kullanıma geçmesi için hâlâ zamana ihtiyaç var
  • Yakın vadede büyük dosya depolamada Git LFS’ye bağımlılık kaçınılmaz görünüyor
  • promisor yaygınlaştığında GitHub’a 100MB üzeri dosya yüklemek de mümkün hale gelebilir

Sonuç: Git’te büyük dosyaların geleceği Git

• Git projesi, büyük dosya sorununu sizin yerinize durmaksızın düşünüyor
• Şu anda hâlâ Git LFS kullanımı gerekiyor
• Ancak partial clone ve large object promisors geliştikçe Git LFS giderek gereksiz hale gelecek; çok yakında büyük dosyaları yalnızca Git ile kolayca yönetmek mümkün olacak
• Gelecekte MP3 kütüphanesini Git’e koyma fikrinin kendisi, büyük ölçekli kullanımın önündeki son engel olabilir