Apa itu Git LFS dan kapan Anda membutuhkannya?

Question

Accepted Answer

**Git LFS** (Large File Storage) adalah sebuah ekstensi untuk menangani **file biner besar** (video, dataset, aset desain, binary besar) secara efisien di Git. Git dirancang untuk teks/kode sumber dan menangani binary besar dengan buruk, jadi LFS menyimpannya secara terpisah sambil menyimpan referensi ringan di repository.

## Masalah: Git dan binary besar

```text
Git stores every version of every file in its history (the full content):
  → LARGE BINARY files (videos, datasets, PSDs, big binaries) bloat the repo ENORMOUSLY:
    - every change stores another full copy (binaries don't diff well)
    - the repo and EVERY clone become huge and slow (clone/fetch download all history)
    - history can't be shrunk easily (the large blobs are permanent)
→ Git is great for source code (text, diffable), POOR for large binaries.
```

## Cara kerja Git LFS

```text
Git LFS replaces large files in the repo with small POINTER files (a reference/hash),
and stores the ACTUAL large files on a separate LFS server:
  → the Git repo stays small (just pointers in history)
  → the actual large files are downloaded on demand (only the versions you need)
→ You work normally; LFS transparently swaps pointers ↔ real files.
```

```bash
git lfs install                    # set up LFS
git lfs track "*.psd"             # track a file type with LFS (records in .gitattributes)
git lfs track "*.mp4"
git add .gitattributes
# now large files of these types go to LFS automatically (pointers in Git)
git lfs ls-files                   # list LFS-tracked files
```

## Kapan menggunakannya

```text
✓ Repos with large binaries: media (video/audio/images), datasets, game assets,
  design files (PSD/Sketch), large compiled artifacts, ML models
✗ Pure source code repos don't need it (Git handles text well)
Alternatives: don't store large artifacts in Git at all (use artifact stores, S3,
  package registries) — sometimes the better choice.
```

## Mengapa ini penting

Memahami Git LFS adalah pengetahuan tingkat senior yang berharga untuk **menangani file biner besar di Git**, masalah nyata untuk proyek tertentu, jadi ini adalah pengetahuan praktis yang berguna.

Isu utama adalah bahwa **Git menangani binary besar dengan buruk**: karena Git menyimpan setiap versi dari setiap file dalam riwayatnya dan binary tidak berdiff dengan baik (setiap perubahan menyimpan salinan penuh lainnya), file biner besar (video, dataset, aset desain, artefak besar) **membengkak repository secara sangat besar** — membuat repo dan setiap clone menjadi besar dan lambat, dengan pembengkakan yang permanen dan sulit dihapus.

Ini adalah masalah nyata, kadang serius untuk proyek yang melibatkan media, dataset, aset game, file desain, atau model ML. **Git LFS** menyelesaikannya dengan menyimpan file besar **secara terpisah** (di server LFS) sambil hanya menyimpan **file pointer** kecil dalam riwayat Git — jadi repository tetap kecil dan ringan, dengan file besar yang sebenarnya diunduh sesuai permintaan (hanya versi yang diperlukan).

Memahami cara kerjanya (pointer di Git, file nyata di LFS, penukaran transparan) dan cara menggunakannya (melacak tipe file melalui `.gitattributes`) adalah pengetahuan praktis untuk proyek yang membutuhkannya.

Sama pentingnya adalah pertimbangan tentang **kapan menggunakannya** (repo dengan binary besar) versus kapan tidak perlu (kode sumber murni, di mana Git menangani teks dengan baik) dan kesadaran akan **alternatif** (kadang tidak menyimpan artefak besar di Git sama sekali — menggunakan toko artefak, S3, atau registri paket — adalah pilihan yang lebih baik).

Ini mencerminkan pengambilan keputusan yang terukur tentang mengelola file besar.

Karena beberapa proyek benar-benar kesulitan dengan binary besar yang membengkak Git (masalah nyata, berdampak), dan karena Git LFS (atau alternatif) adalah solusinya — menjaga repo dapat dikelola sambil menangani file besar — memahami Git LFS, masalah yang diselesaikannya, cara kerjanya, dan kapan menggunakannya versus alternatif adalah pengetahuan tingkat senior yang berharga untuk mengelola repository dengan file besar secara efektif, topik yang berguna untuk proyek yang menangani media, data, atau aset besar.