Hva er Git LFS og når trenger du det?

Question

Accepted Answer

**Git LFS** (Large File Storage) er en utvidelse for effektiv håndtering av **store binære filer** (videoer, datasett, designressurser, store binærer) i Git. Git er designet for tekst/kildekode og håndterer store binærer dårlig, så LFS lagrer dem separat mens det opprettholder lette referanser i depotet.

## Problemet: Git og store 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.
```

## Hvordan Git LFS fungerer

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

## Hvorfor det betyr noe

Å forstå Git LFS er verdifull kunnskap på seniorplan for **håndtering av store binære filer i Git**, et reelt problem for visse prosjekter, så det er nyttig praktisk kunnskap.

Kjerneproblematiikken er at **Git håndterer store binærer dårlig**: fordi Git lagrer hver versjon av hver fil i sin historie, og binærer fungerer ikke godt med diff (hver endring lagrer en annen full kopi), så store binære filer (videoer, datasett, designressurser, store artefakter) **oppblåser depotet enormt** — noe som gjør depoet og hver klon stort og tregt, og oppblåsingen er permanent og vanskelig å fjerne.

Dette er et reelt, noen ganger alvorlig problem for prosjekter som involverer media, datasett, spilleresurser, designfiler eller ML-modeller. **Git LFS** løser det ved å lagre store filer **separat** (på en LFS-server) mens det bare opprettholder små **pekerfiler** i Git-historikken — slik at depotet forblir lite og lett, med faktiske store filer lastet ned etter behov (kun versjonene som er nødvendige).

Å forstå hvordan det fungerer (pekere i Git, virkelige filer i LFS, transparent bytte) og hvordan man bruker det (sporing av filtyper via `.gitattributes`) er den praktiske kunnskapen for prosjekter som trenger det.

Like viktig er vurderingen om **når man skal bruke det** (depoter med store binærer) kontra når det er unødvendig (ren kildekode, der Git håndterer tekst godt) og bevissthet om **alternativer** (noen ganger er det bedre valg å ikke lagre store artefakter i Git i det hele tatt — å bruke artefaktlagre, S3 eller pakkeregistre — er det bedre valget).

Dette reflekterer solid beslutningstaking om håndtering av store filer.

Ettersom noen prosjekter genuint sliter med at store binærer oppblåser Git (et reelt, betydningsfullt problem), og ettersom Git LFS (eller alternativer) er løsningen — å holde depoter håndterlbare mens man håndterer store filer — er forståelse av Git LFS, problemet det løser, hvordan det fungerer, og når man skal bruke det kontra alternativer verdifull kunnskap på seniorplan for effektiv håndtering av depoter med store filer, et nyttig emne for prosjekter som håndterer media, data eller store ressurser.