What is Git LFS and when do you need it?

Question

Accepted Answer

**Git LFS** (Large File Storage) is an extension for handling **large binary files** (videos, datasets, design assets, large binaries) efficiently in Git. Git is designed for text/source code and handles large binaries poorly, so LFS stores them separately while keeping lightweight references in the repository.

## The problem: Git and large binaries

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

## How Git LFS works

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

## When to use it

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

## Why it matters

Understanding Git LFS is valuable senior-level knowledge for **handling large binary files in Git**, a real problem for certain projects, so it's useful practical knowledge.

The core issue is that **Git handles large binaries poorly**: because Git stores every version of every file in its history and binaries don't diff well (each change stores another full copy), large binary files (videos, datasets, design assets, large artifacts) **bloat the repository enormously** — making the repo and every clone huge and slow, with the bloat being permanent and hard to remove.

This is a genuine, sometimes serious problem for projects involving media, datasets, game assets, design files, or ML models. **Git LFS** solves it by storing large files **separately** (on an LFS server) while keeping only small **pointer files** in the Git history — so the repository stays small and lightweight, with actual large files downloaded on demand (only the versions needed).

Understanding how it works (pointers in Git, real files in LFS, transparent swapping) and how to use it (tracking file types via `.gitattributes`) is the practical knowledge for projects that need it.

Equally important is the judgment about **when to use it** (repos with large binaries) versus when it's unnecessary (pure source code, where Git handles text well) and awareness of **alternatives** (sometimes not storing large artifacts in Git at all — using artifact stores, S3, or package registries — is the better choice).

This reflects sound decision-making about managing large files.

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.