Vad är Git LFS och när behöver du det?

Question

Accepted Answer

**Git LFS** (Large File Storage) är ett tillägg för att hantera **stora binära filer** (videor, dataset, designtillgångar, stora binärer) effektivt i Git. Git är designat för text/källkod och hanterar stora binärer dåligt, så LFS lagrar dem separat medan små referenserna hålls i repositoryt.

## Problemet: Git och stora binärer

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

## Hur Git LFS fungerar

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

## När du ska använda det

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

## Varför det är viktigt

Att förstå Git LFS är värdeful kunskap på seniornivå för **hantering av stora binära filer i Git**, ett verkligt problem för vissa projekt, så det är användbar praktisk kunskap.

Kärnproblemet är att **Git hanterar stora binärer dåligt**: eftersom Git lagrar varje version av varje fil i sin historia och binärer skiljer sig dåligt åt (varje förändring lagrar en annan fullständig kopia), stora binära filer (videor, dataset, designtillgångar, stora artefakter) **överbelastas repositoryt enormt** — vilket gör repot och varje klon stor och långsam, med överbelastningen permanent och svår att ta bort.

Detta är ett verkligt, ibland allvarligt problem för projekt som involverar media, dataset, spelresurser, designfiler eller ML-modeller. **Git LFS** löser det genom att lagra stora filer **separat** (på en LFS-server) medan endast små **pekerfiler** behålls i Git-historiken — så repositoryt förblir litet och lätt, med faktiska stora filer nedladdade på begäran (bara de versioner som behövs).

Att förstå hur det fungerar (pekare i Git, verkliga filer i LFS, transparent utbyte) och hur man använder det (spårning av filtyper via `.gitattributes`) är den praktiska kunskapen för projekt som behöver det.

Lika viktigt är bedömningsförmågan om **när man ska använda det** (repos med stora binärer) kontra när det är onödigt (ren källkod, där Git hanterar text bra) och medvetenhet om **alternativ** (ibland är det bättre att inte lagra stora artefakter i Git alls — att använda artefaktlager, S3 eller paketregister — är det bättre valet).

Detta återspeglar sund beslutsfattning om hantering av stora filer.

Since some projects genuinely struggle with large binaries bloating Git (a real, impactful problem), and since Git LFS (or alternatives) is the solution — keeping repos manageable while handling large files — understanding Git LFS, the problem it solves, how it works, and when to use it versus alternatives is valuable senior-level knowledge for managing repositories with large files effectively, a useful topic for projects dealing with media, data, or large assets.