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

[GN⁺]

Komentar Hacker News

• Bahkan dulu dengan svn, direktori kerja 150GB yang berisi banyak file biner besar tetap berjalan tanpa banyak masalah, sedangkan git tidak demikian. Saya penasaran kenapa svn mengambil pendekatan berbeda untuk file biner besar dibanding git, dan apakah git sebenarnya tidak bisa melakukan hal yang sama. Selain itu, fitur yang benar-benar penting saat menangani data biner adalah penguncian file; hanya satu orang yang boleh mengerjakan file tertentu dan yang lain harus read-only agar terhindar dari masalah merge yang membingungkan. Saya juga kurang paham apakah memindahkan file besar ke sistem eksternal benar-benar memperbaiki masalah performa atau keandalan. Pada akhirnya repositorinya hanya berbeda lokasi; repositori tetaplah repositori. Offload ini pada dasarnya terasa seperti cara public git forge menghindari biaya penyimpanan file besar

  • git dan svn punya desain yang sepenuhnya berbeda. git benar-benar terdistribusi, jadi setiap repositori harus memiliki seluruh riwayat semua file, dan konsep locking menjadi tidak bermakna. Tinggal pilih sistem kontrol versi yang sesuai dengan proyek; bukan berarti git harus cocok untuk semuanya

• Saya suka konsep large object promisors. Kalau bisa mudah dihubungkan ke S3 atau sejenisnya, saya rasa orang akan langsung pindah dari LFS yang ada sekarang. S3 sangat cocok untuk version control file biner besar. Dengan intelligent tiering, data yang makin lama tidak dipakai bisa otomatis dipindahkan ke storage tier yang lebih murah. Kalaupun butuh setengah hari untuk memulihkan data berusia 10 tahun, tidak masalah

  • Saya juga berpikir begitu. Saya tidak mengerti kenapa dari awal ini tidak dijadikan cara bawaan. Saya menjalankan server git LFS kecil sendiri, dan kalau git mendukung S3 secara native, saya siap langsung pindah

  • Di tempat kerja sekarang kami meng-cache objek LFS ke bucket untuk menghemat biaya. Setiap kali menjalankan PR, kami mengambil daftar file lewat git lfs ls-files, mengambilnya dari gcp, menyimpan objek secara lokal dengan git lfs checkout, lalu menjalankan pull agar hanya objek yang belum ada saja yang diambil tambahan. File yang belum ter-cache diunggah kembali ke bucket dengan gcloud storage rsync. Dari sisi developer, tidak perlu konfigurasi tambahan; cukup pull objek baru saja, dan UI GitHub juga tidak jadi membingungkan soal status repositori. Dulu kami sempat mempertimbangkan menjalankan backend LFS sendiri, tapi cara ini menyelesaikan masalah terbesar untuk saat ini. GitHub mengenakan biaya trafik yang berlebihan setiap kali file LFS diambil di CI, dan karena batas cache 10GB serta tidak bisa dibagikan antar-branch, file-file itu harus diunduh ulang terus. Saya bahkan ingin menambah kapasitas cache dengan membayar kalau perlu, tapi ternyata itu pun tidak ada opsinya. Untuk menerapkannya ke developer, cukup tambahkan git hook, sesederhana itu

  • Apakah S3 itu layanan yang berhubungan dengan Amazon?

• Saya setuju ada banyak hal buruk pada Git LFS, tetapi saya tidak setuju kalau disebut ada vendor lock-in. GitHub menyediakan klien dan server open source, jadi klaim itu tidak adil. Namun, LFS memang tidak berfungsi untuk pekerjaan offline/sneakernet, yang mungkin bukan kasus umum tetapi tetap layak disebut. large object promisor tampak seperti memindahkan kompleksitas sisi klien dari LFS ke server, jadi rasanya kompleksitasnya hanya berpindah tempat. Kalau server git mengunggah file ke server LFS dan object store, itu akan membawa trade-off lain. Saya penasaran apa yang terjadi bila public git server menyembunyikan promisor remote saat proses upload

  • Saya benar-benar merasa LFS itu jelek. Implementasi servernya juga berantakan, dan isi objek bercampur dengan cara penyimpanannya. Mekanisme opt-in-nya juga buruk sekali, jadi kalau dipakai tanpa berpikir, yang muncul malah file teks kecil alih-alih file yang sebenarnya diinginkan. Saya tidak tahu apakah solusi baru ini lebih baik, tetapi jelas LFS memang tidak bagus

  • Masalah lain Git LFS yang baru saya ketahui belakangan adalah bahwa migrasi mencemari .gitattributes pada commit-commit sebelumnya juga. Artinya, kalau urutan commit adalah A→B→C dan file besar baru ditambahkan ke LFS hanya di C, maka A dan B juga akan memiliki .gitattributes yang menunjuk ke file LFS yang sebenarnya belum ada. Saat migrasi, .gitattributes menyebar mundur sepanjang riwayat karena tidak memeriksa apakah entitas itu benar-benar ada pada commit saat itu

  • Dulu Git LFS tidak mendukung SSH, jadi harus memakai sertifikat SSL, dan ini menjadi hambatan masuk bagi pengguna yang self-hosting di rumah. Sepertinya GitLab baru-baru ini menambahkan patch dukungan SSH

• Di kelas rekayasa perangkat lunak, kami dulu disarankan untuk tidak memasukkan file besar (media dan semacamnya) ke Git, melainkan ke artifact repository seperti Artifactory. Dengan begitu, file bisa didistribusikan sebagai snapshot dependency, dan build system bisa mengatur agar hanya versi terbaru yang diambil otomatis. File lama yang menumpuk secara lokal di mesin rekan kerja juga bisa langsung dibersihkan hanya dengan mengosongkan cache build system

  • Cara ini terasa agak seperti git submodule. Kalau submodule memang menyelesaikan masalah, orang-orang pasti sudah memakainya. git submodule juga mendukung shallow clone (tautan terkait: https://stackoverflow.com/questions/2144406/how-to-make-shallow-git-submodules). Saya sendiri belum pernah menghadapi masalah file besar, jadi saya penasaran kenapa cara ini tidak berhasil. Kekurangan yang disebut di SO juga tidak terlihat terlalu besar

  • Saya penasaran apakah di kelas itu juga diajarkan arsitektur sistem CI/CD. Banyak engineer baru sekarang tidak terbiasa dengan keseluruhan arsitektur yang terintegrasi dengan GitLab, Artifactory, CodeSonar, Anchore, dan sebagainya

  • Cara ini juga punya kekurangan. Sistem CI/CD maupun developer membutuhkan kredensial tambahan. Commit juga bertambah menjadi beberapa tahap, karena artifact ID harus diketahui lebih dulu, dan saat mencoba mengotomatiskannya dengan git hook, pada akhirnya kompleksitasnya jadi mirip git-lfs

• Tulisan ini menilai LFS secara tidak adil. LFS tidak terikat pada GitHub dan protokolnya juga terbuka. Kekurangan LFS adalah konsekuensi yang tidak terhindarkan karena ia merupakan ekstensi git, dan promisor pada dasarnya juga konsep yang sama dengan LFS. Bedanya, ini dibenamkan ke dalam git sehingga UX-nya sedikit lebih baik

  • Sekali sebuah repositori memakai LFS, repositori itu terkunci selamanya. Untuk mengurangi ruang yang terpakai, satu-satunya cara adalah menghapus repositorinya sendiri, dan hal ini pun tidak dijelaskan dengan jelas secara resmi. Kami mengalami sendiri masalah ini saat meneliti statistik GitHub perusahaan dengan memasukkan file DB terkompresi besar ke LFS

• Ini bukan solusi yang sesungguhnya. git LFS juga hanya tambalan sementara, dan menambahkan argumen filter saat clone juga bukan jawaban mendasar. git clone adalah perintah pertama yang dipelajari semua orang, tetapi sekarang kita harus selalu ingat menambahkan filter setiap kali memakainya. Kalau lupa, hanya membuang waktu; dan bahkan kalau berhasil pun, repositori hasil clone mungkin tidak bekerja dengan benar. Pada akhirnya, solusi mendasar adalah beralih ke model seperti rsync yang efisien mengambil file terbaru lebih dulu. git tidak terlalu pandai melakukan perubahan mendasar seperti itu

  • Sangat setuju. git selalu “menyelesaikan” masalah dengan menambahkan satu flag lagi, tetapi kebanyakan pengguna bahkan tidak tahu fitur itu ada. Kalau default-nya diperbaiki, masalahnya bisa diatasi tanpa harus merusak kompatibilitas

  • repositori hasil clone mungkin tidak bekerja dengan benar
    Sebenarnya yang hilang hanya riwayat blob-nya

  • Dibilang rsync sudah memecahkan masalah ini, tapi bentuk nyatanya seperti apa? Bukan algoritmenya, melainkan apa yang sebenarnya muncul di filesystem lokal saat pengguna menjalankan "git clone"

  • Jika sebagian besar ukuran repositori berasal dari revisi-revisi lama, maka pendekatan ala rsync yang lebih dulu mengambil versi terbaru adalah solusi yang paling cocok bagi kebanyakan pengguna

• Saya sangat senang dukungan file besar akan ditambahkan ke Git core. Bahkan kalau tetap berupa solusi eksternal pun, strukturnya pada akhirnya tetap opt-in. Saya ingin mengurangi jumlah perintah semaksimal mungkin dan membuatnya seamless, jadi API-nya dirancang agar hanya terbatas pada filter smudge/clean di file .gitattributes. Selain itu, saya juga bekerja sama langsung dengan Atlassian dan Microsoft untuk menghilangkan vendor lock-in, dan API file locking juga banyak dibantu oleh Atlassian. LFS disediakan sebagai open source dengan dukungan kompatibilitas pada tiga host

• Kami sedang mengembangkan oxen untuk mengatasi masalah yang kami alami di git maupun git-lfs. Antarmukanya tetap mengikuti git, tetapi berjalan jauh lebih cepat untuk file besar dan lingkungan monorepo dengan jutaan file. Kami menyediakan CLI dan server open source, jadi kalau tertarik, mohon beri masukan
  https://github.com/Oxen-AI/Oxen

• Cara penyimpanan git sendiri juga perlu dirombak seperti tool backup modern semacam restic atau borg, dengan content-defined chunking berbasis konten untuk file dan direktori

• Salah satu kekurangan GitLFS yang tidak disebut adalah masalah autentikasi; kalau tidak memakai SSH-agent, bahkan untuk satu kali push pun autentikasi bisa terjadi berkali-kali. Dari pengalaman pribadi, saya pernah harus melakukannya lebih dari dua atau tiga kali