Co je Git LFS a kdy ho potřebujete?

Question

Accepted Answer

**Git LFS** (Large File Storage) je rozšíření pro efektivní práci s **velkými binárními soubory** (videa, datasety, designové assety, velké binárky) v Gitu. Git je navržen pro text/zdrojový kód a velké binární soubory zvládá špatně, proto LFS je ukládá odděleně a v repozitáři si udržuje pouze lehké reference.

## Problém: Git a velké binární soubory

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

## Jak Git LFS funguje

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

## Kdy ho používat

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

## Proč je to důležité

Rozdíl v tom, že **Git zvládá velké binární soubory špatně**: protože Git ukládá každou verzi každého souboru v historii a binární soubory se dobře nediffují (každá změna uloží další úplnou kopii), velké binární soubory (videa, datasety, designové assety, velké artefakty) **enormně nafouknou repozitář** — činí repo i každý klon obrovský a pomalý, s navíc trvalým a těžko odstranitelným nafoukem.

Jde o skutečný, někdy vážný problém pro projekty se médii, datasety, game assety, designovými soubory nebo ML modely. **Git LFS** to řeší tím, že ukládá velké soubory **odděleně** (na LFS server) a v Gitu si udržuje jen malé **pointer soubory** — repozitář tak zůstane malý a lehký, se samotnými velkými soubory staženými na vyžádání (jen verze, které jsou potřebné).

Rozmět, jak to funguje (pointery v Gitu, skutečné soubory v LFS, transparentní výměna) a jak to používat (sledování typů souborů přes `.gitattributes`) je praktické vědomí pro projekty, které to potřebují.

Rovněž důležité je uvážení o **kdy to používat** (repozitáře s velkými binárkami) versus kdy to není potřeba (čistě zdrojový kód, kde Git zvládá text dobře) a povědomí o **alternativách** (někdy není uložení velkých artefaktů v Gitu vůbec správné řešení — použití artifact stores, S3 nebo package registries je lepší volba).

To odráží zdvihnuté rozhodování o správě velkých souborů.

Protože některé projekty skutečně trápí velké binární soubory nafukující Git (skutečný, dopadový problém), a protože Git LFS (nebo alternativy) je řešení — udržování repozitářů ovladatelných při práci s velkými soubory — je pochopeníí Git LFS, problému, který řeší, jak funguje, a kdy ho používat versus alternativy, cenné vědomí seniorní úrovně pro správu repozitářů s velkými soubory, užitečné téma pro projekty pracující s médii, daty nebo velkými assety.