Что такое Git LFS и когда он необходим?

Question

Accepted Answer

**Git LFS** (Large File Storage) — это расширение для эффективной работы с **большими бинарными файлами** (видео, датасеты, дизайн-ассеты, крупные бинарники) в Git. Git спроектирован для текста и исходного кода, и плохо работает с большими бинарниками, поэтому LFS хранит их отдельно, сохраняя в репозитории только лёгкие ссылки.

## Проблема: Git и большие бинарные файлы

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

## Как работает Git LFS

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

## Когда использовать

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

## Почему это важно

Понимание Git LFS — это ценное знание уровня senior для **работы с большими бинарными файлами в Git**, реальная проблема для определённых проектов, поэтому это полезное практическое знание.

Основная проблема в том, что **Git плохо работает с большими бинарниками**: поскольку Git хранит в истории каждую версию каждого файла, а бинарники плохо поддаются дифферированию (каждое изменение сохраняет ещё одну полную копию), большие бинарные файлы (видео, датасеты, дизайн-ассеты, крупные артефакты) **раздувают репозиторий колоссально** — репозиторий и каждый клон становятся огромными и медленными, раздувание становится постоянным и его сложно удалить.

Это подлинная, иногда серьёзная проблема для проектов с медиа, датасетами, игровыми ассетами, дизайн-файлами или ML-моделями. **Git LFS** решает это, храня большие файлы **отдельно** (на LFS-сервере), сохраняя в истории Git только небольшие **файлы-ссылки** — таким образом репозиторий остаётся компактным и лёгким, а большие файлы загружаются по требованию (только нужные версии).

Понимание того, как это работает (ссылки в Git, реальные файлы в LFS, прозрачный обмен) и как это использовать (отслеживание типов файлов через `.gitattributes`) — это практическое знание для проектов, которые его нужно.

Равно важно понимание **когда его использовать** (репозитории с большими бинарниками) в сравнении с тем, когда это ненужно (чистый исходный код, где Git хорошо работает с текстом), и осведомлённость об **альтернативах** (иногда вообще не хранить большие артефакты в Git — использовать хранилища артефактов, S3 или реестры пакетов — лучший выбор).

Это отражает здравое суждение об управлении большими файлами.

Поскольку некоторые проекты действительно страдают от раздувания Git большими бинарниками (реальная, серьёзная проблема), и поскольку Git LFS (или альтернативы) — это решение — сохранение управляемости репозиториев при работе с большими файлами — понимание Git LFS, проблемы, которую он решает, того, как он работает, и когда использовать его или альтернативы, является ценным знанием уровня senior для эффективного управления репозиториями с большими файлами, полезной темой для проектов, работающих с медиа, данными или крупными ассетами.