Masa depan file berukuran besar di Git adalah Git itu sendiri

• Proyek Git belakangan ini secara resmi mulai menangani langsung masalah pengelolaan file berukuran besar
• Git LFS adalah solusi sementara yang menimbulkan berbagai biaya dan ketergantungan vendor bagi pengguna
• Dengan fitur partial clone terbaru, sebagian besar peran LFS kini bisa digantikan hanya dengan Git itu sendiri
• Ke depan, solusi baru bernama large object promisor juga sedang disiapkan untuk diintegrasikan ke Git resmi
• Dengan perubahan ini, solusi akhir untuk pengelolaan file berukuran besar diperkirakan akan bermuara pada Git itu sendiri, bukan ekstensi eksternal

---

Masalah file besar di Git dan perubahannya

• Jika ada musuh utama Git, itu adalah file berukuran besar
• File besar membuat repositori Git membengkak, memperlambat git clone, dan berdampak buruk pada sebagian besar lingkungan hosting

Munculnya Git LFS dan keterbatasannya

• Pada 2015, GitHub merilis Git LFS untuk mengakali masalah file besar
• Namun Git LFS sendiri menambahkan kompleksitas baru dan biaya penyimpanan tambahan

• Komunitas Git diam-diam telah lama memikirkan akar masalah file besar, dan rilis resmi Git terbaru kini menunjukkan arah baru untuk mengelola file besar tanpa LFS

Cara yang bisa dipakai sekarang juga: mengganti Git LFS dengan partial clone

• Prinsip kerja partial clone

  • Git LFS: file besar diletakkan di luar repositori, lalu hanya file yang diperlukan yang diunduh untuk dikerjakan
  • Git partial clone (diperkenalkan pada 2017):
    • melakukan clone sambil mengecualikan blob di atas ukuran tertentu dengan opsi --filter
    • hanya mengunduh file besar terkait dari server saat benar-benar diperlukan
      > Dengan partial clone, Anda tidak perlu mengunduh lebih dulu [aset biner berukuran besar] saat Clone dan Fetch, sehingga waktu unduh dan penggunaan disk dapat dikurangi
      > - Partial Clone Design Notes, git-scm.com

• Kesamaan partial clone dan LFS

  • 1. Meminimalkan ukuran checkout: hanya mengambil versi terbaru dan melewati seluruh riwayat file
  • 2. Clone lebih cepat: karena tidak ada transfer file besar, kecepatan clone meningkat
  • 3. Setup lebih cepat: berbeda dengan shallow clone, seluruh riwayat proyek tetap bisa diakses

• Contoh penggunaan partial clone

  • Contoh nyata kecepatan clone dan pemakaian disk saat menyalin repo dengan banyak riwayat file PNG besar:
    • clone biasa memakan hampir 4 menit dan 1.3GB ruang
    • dengan partial clone dan batas blob 100KB, clone selesai dalam 6 detik dan memakai 49MB
    • dibandingkan aslinya, kecepatan clone membaik 97% dan ukuran checkout menyusut 96%

• Keterbatasan partial clone

  • Jika data yang difilter dibutuhkan (misalnya git diff, git blame, git checkout), Git akan meminta file tersebut ke server
  • Ini adalah karakteristik yang sama dengan Git LFS
  • Dalam praktik kerja, jarang ada kebutuhan menjalankan blame pada file biner

Masalah pada Git LFS

• Ketergantungan vendor yang tinggi: implementasi GitHub hanya mendukung server miliknya sendiri, sehingga menimbulkan biaya dan ketergantungan
• Masalah biaya: untuk penyimpanan 50GB, GitHub LFS sekitar $40 per tahun, sedangkan Amazon S3 $13
• Sulit dibatalkan: sekali berpindah ke LFS, tidak bisa kembali seperti semula tanpa menulis ulang riwayat
• Biaya setup berkelanjutan: semua kolaborator wajib memasang LFS; jika tidak, yang muncul bukan file aslinya melainkan file metadata, yang memicu kebingungan

Prospek ke depan: Large Object Promisor

• File berukuran besar juga menimbulkan masalah biaya di platform hosting seperti GitHub dan GitLab
• Git LFS menurunkan biaya server dengan memindahkan file besar ke CDN

• Apa itu Large Object Promisor?

  • Awal tahun ini, Git secara resmi melakukan merge fitur bernama large object promisor
  • Fitur ini, seperti LFS, mengurangi beban penyimpanan di sisi server, tetapi sangat menurunkan kompleksitas bagi pengguna
    > Upaya ini ditujukan untuk meningkatkan pekerjaan di sisi server, khususnya untuk blob besar yang sudah dikompresi dalam format biner
    > Ini adalah solusi yang menjadi alternatif bagi Git LFS
    > – Large Object Promisors, git-scm.com

• Cara kerjanya

  • 1. Pengguna melakukan push file besar ke host Git
  • 2. Host memindahkan file besar tersebut ke backend promisor
  • 3. Saat clone, host Git memberikan informasi promisor ke klien
  • 4. Klien kemudian otomatis mengambil file besar dari promisor itu bila diperlukan

• Status adopsi saat ini dan tantangannya

  • Promisor untuk file besar masih dalam pengembangan, dan sebagian kode sudah di-merge ke Git pada Maret 2025
  • Implementasi tambahan dan pembahasan isu yang belum terselesaikan sedang berlangsung di GitLab dan lainnya
  • Masih butuh waktu sebelum diadopsi secara luas
  • Untuk sementara, ketergantungan pada Git LFS untuk penyimpanan file besar masih tak terhindarkan
  • Jika promisor sudah tersebar luas, file di atas 100MB diperkirakan juga bisa diunggah ke GitHub

Kesimpulan: masa depan file besar di Git adalah Git

• Proyek Git terus memikirkan masalah file berukuran besar untuk Anda
• Saat ini, penggunaan Git LFS masih tetap diperlukan
• Namun seiring berkembangnya partial clone dan large object promisors, Git LFS akan makin tidak diperlukan, dan dalam waktu yang tidak lama lagi pengelolaan file besar dengan mudah hanya menggunakan Git akan menjadi kenyataan
• Di masa depan, satu-satunya penghalang terakhir untuk penggunaan file besar mungkin hanya keinginan memasukkan pustaka MP3 ke dalam Git