什么是 Git LFS，你何时需要它？

Question

什么是 Git LFS，你何时需要它？

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 是**处理 Git 中大型二进制文件**的高级知识，这对某些项目来说是一个真实存在的问题，因此了解它具有实用价值。

核心问题是 **Git 对大型二进制文件的处理效率低下**：由于 Git 在历史记录中存储每个文件的每个版本，而二进制文件的差异不明显（每次更改都会存储另一个完整副本），大型二进制文件（视频、数据集、设计资源、大型构件）会**大幅膨胀仓库** — 使得仓库和每次克隆都变得巨大且缓慢，而且膨胀是永久的，难以清除。

これは、媒体、数据集、游戏资源、设计文件或机器学习模型涉及的项目中一个真实且有时很严重的问题。**Git LFS** 通过**单独存储**大型文件（在 LFS 服务器上）同时在 Git 历史中仅保留小型**指针文件**来解决这个问题 — 这样仓库保持小而轻量，实际大型文件按需下载（只下载所需的版本）。

理解它的工作原理（Git 中的指针、LFS 中的实际文件、透明交换）以及如何使用它（通过 `.gitattributes` 跟踪文件类型）是需要它的项目的实用知识。

同样重要的是关于**何时使用它**（包含大型二进制文件的仓库）与何时不必要（纯源代码，Git 处理文本效果很好）的判断能力，以及**替代方案**的认识（有时根本不在 Git 中存储大型构件 — 使用构件存储、S3 或包注册表 — 是更好的选择）。

这反映了关于大文件管理的健全决策制定。

由于某些项目确实因大型二进制文件导致 Git 膨胀而苦恼（这是一个真实且有影响力的问题），并且 Git LFS（或替代方案）是解决方案 — 在处理大型文件的同时保持仓库可管理 — 理解 Git LFS、它所解决的问题、它的工作原理以及何时相对于替代方案使用它是有效管理包含大型文件的仓库的高级知识，是涉及媒体、数据或大型资源的项目的有用主题。