Apa iku Git LFS lan kapan sampeyan mbutuhake?

Question

Accepted Answer

**Git LFS** (Large File Storage) minangka extension kanggo nangani **file biner gedhe** (video, dataset, asset desain, biner gedhe) kanthi efisien ing Git. Git dirancang kanggo teks/source code lan nangani biner gedhe kanthi ora apik, mula LFS nyimpen kasebut kanthi terpisah nalika tetep nyimpen referensi enteng ing repository.

## Masalah: Git lan biner gedhe

```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 Git LFS Berjalan

```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 enggo digunakake

```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.
```

## Kaluwargan apa makna

Pamahaman Git LFS minangka ilmu level senior saben-sebutane kanggo **nangani file biner gedhe ing Git**, masalah nyata kanggo project tartamtu, mula iku katrangan praktis sing guna.

Masalah inti yaiku **Git nangani biner gedhe kanthi ora apik**: amarga Git nyimpen saben versi saben file ing sajarah lan biner ora bedah apik (saben owah nyimpen siji kopian lengkap), file biner gedhe (video, dataset, asset desain, artifact gedhe) **ngembung repository kanthi luar biasa** — ndadakake repo lan saben clone gedhe lan alon, kanthi embung sing tetep lan angel dicopot.

Iki masalah asli, kadhangkala serius kanggo project sing nglibatake media, dataset, game asset, file desain, utawa model ML. **Git LFS** nglesi kanthi nyimpen file gedhe **kanthi terpisah** (ing server LFS) nalika tetep nyimpen mung **file pointer** cilik ing sajarah Git — mula repository tetep cilik lan enteng, kanthi file gedhe diunduh miturut kabutuhan (mung versi sing dibutuhake).

Pamahaman carane berjalan (pointer ing Git, file asli ing LFS, panukaran transparan) lan carane nggunakake (nglacak tipe file liwat `.gitattributes`) minangka ilmu praktis kanggo project sing mbutuhake.

Sama pentinge yaiku pertimbangan babagan **kapan nggunakake** (repo kanthi biner gedhe) lawan kapan ora perlu (pure source code, ing ngendi Git nangani teks apik) lan kesadaran babagan **alternatif** (kadhangkala ora nyimpen artifact gedhe ing Git - nggunakake artifact store, S3, utawa package registry - minangka pilihan luwih apik).

Iki cerminake keputusan apik babagan nangani file gedhe.

Amarga sawetara project tulung banget kanthi biner gedhe ngembung Git (masalah asli, impactful), lan amarga Git LFS (utawa alternatif) minangka solusi — tetep repo kamanah nalika nangani file gedhe — pamahaman Git LFS, masalah sing dilesi, carane berjalan, lan kapan nggunakake lawan alternatif minangka ilmu level senior saben-sebutane kanggo nangani repository kanthi file gedhe kanthi efektif, topik guna kanggo project sing nglibatake media, data, utawa asset gedhe.