Git LFS: Mengelola File Besar

Kenapa Git benci file besar

Git dirancang untuk teks: kode sumber, markdown, config. Setiap versi file disimpan selamanya di riwayat, dan untuk teks itu murah karena Git hanya menyimpan selisihnya (delta). Tapi untuk file biner seperti video 500 MB atau model AI 2 GB, tidak ada delta yang efisien: setiap versi menyimpan salinan penuh. Clone repo berisi beberapa file raksasa berarti mengunduh gigabyte yang tidak pernah kamu butuhkan versinya satu per satu.

GitHub menegakkan batas keras: file tunggal di atas 100 MB ditolak saat push, dan kamu dapat peringatan mulai 50 MB. Jadi "push dulu, pikir belakangan" bukan strategi untuk aset besar. Solusinya adalah Git LFS (Large File Storage): Git tetap mencatat file-nya, tapi isi aslinya disimpan di server terpisah dan diunduh hanya saat dibutuhkan.

Cara kerja dan perintah dasarnya

LFS bekerja dengan trik elegan: di repo Git, file besarmu diganti pointer teks kecil berisi hash dan ukuran, sedangkan blob aslinya tinggal di server LFS. Saat checkout, Git mengunduh blob yang dibutuhkan saja. Riwayat Git tetap ramping karena yang berversi hanyalah pointer mungil.

Setup satu kali per mesin:

git lfs install

Lalu tentukan pola file yang dikelola LFS di repo:

git lfs track "*.psd"
git lfs track "*.mp4"
git lfs track "assets/models/*"

Perintah ini membuat (atau memperbarui) file .gitattributes yang wajib ikut ter-commit:

cat .gitattributes

Contoh output:

*.psd filter=lfs diff=lfs merge=lfs -text
*.mp4 filter=lfs diff=lfs merge=lfs -text
assets/models/* filter=lfs diff=lfs merge=lfs -text

Setelah itu alur kerja normal: git add, git commit, git push seperti biasa. LFS mencegat file yang cocok pola dan mengunggah blob-nya ke server LFS secara transparan. Rekan tim yang clone akan mendapat pointer lalu blob diunduh otomatis saat checkout, tanpa perintah khusus.

Kapan perlu, kapan tidak

Pakai LFS untuk: aset game (tekstur, audio), video dan file desain besar, dataset machine learning, file CAD, atau binary release yang memang harus berversi di repo. Jangan pakai LFS untuk: kode sumber dan teks (tidak ada manfaatnya, malah menambah kompleksitas), file yang berubah setiap menit (setiap versi menyimpan blob penuh baru), atau file yang sebenarnya lebih cocok di CDN/storage khusus.

Satu peringatan penting: LFS bukan gratis tanpa batas. Akun gratis mendapat 1 GB penyimpanan dan 1 GB bandwidth per bulan. Setiap clone menghitung bandwidth, jadi repo LFS yang di-clone 50 orang dengan aset 500 MB akan menghabiskan kuota dengan cepat. Untuk proyek pribadi dan tim kecil ini cukup, tapi pantau pemakaian di Settings, Billing. Kalau asetmu raksasa dan publik, pertimbangkan hosting file di tempat khusus (misalnya release attachment atau object storage) dan hanya tautkan URL-nya di repo.

Kesalahan umum pemula

Salah: menjalankan git lfs track setelah file besar sudah ter-commit biasa, lalu heran kenapa riwayat tetap gendut. Track hanya berlaku untuk commit berikutnya; file yang sudah masuk riwayat tetap berukuran penuh selamanya kecuali riwayat ditulis ulang. Benar: tentukan pola LFS sebelum file besar pertama di-commit. Kalau sudah telanjur, migrasi riwayat butuh git lfs migrate, operasi penulisan ulang riwayat yang harus dikoordinasikan dengan tim.

Salah: lupa meng-commit .gitattributes, sehingga di laptopmu file ter-track LFS tapi di laptop teman ia masuk sebagai file Git biasa yang raksasa. Benar: .gitattributes adalah bagian dari konfigurasi repo, selalu commit dan push seperti kode lainnya.