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を理解することは、**Gitで大きなバイナリファイルを扱う**ためのシニアレベルの知識として価値があります。これは特定のプロジェクトにとって実際の問題であり、実用的な知識として有用です。

根本的な問題は、**Gitは大きなバイナリを扱うのが下手**だということです。Gitはすべてのファイルのすべてのバージョンを履歴に保存し、バイナリはdiffしにくいため（変更のたびに全体のコピーが保存される）、大きなバイナリファイル（ビデオ、データセット、デザインアセット、大型アーティファクト）は**リポジトリを極度に肥大化させます**。その結果、リポジトリとすべてのクローンが巨大になり遅くなり、肥大化は永続的で削除が困難になります。

これはメディア、データセット、ゲームアセット、デザインファイル、またはMLモデルを扱うプロジェクトにおいて、本当に起こる、時として深刻な問題です。**Git LFS**はこれを解決します。大きなファイルを**別々に**（LFSサーバー上に）保存し、Git履歴には小さな**ポインタファイル**のみを保持することで、リポジトリは小さく軽量に保たれ、実際の大きなファイルは必要なときだけオンデマンドでダウンロードされます（必要なバージョンのみ）。

その動作原理（Gitのポインタ、LFS上の実ファイル、透過的な交換）と使用方法（`.gitattributes`でファイルタイプを追跡）を理解することは、それが必要なプロジェクトにとって実用的な知識です。

同じくらい重要なのは、**いつ使うべきか**（大きなバイナリがあるリポジトリ）対**不要な場合**（Gitがテキストを上手に扱うピュアソースコード）についての判断であり、また**代替案**への意識です。時には大きなアーティファクトをGitに保存しないこと（アーティファクトストア、S3、またはパッケージレジストリを使用する）がより良い選択肢です。

これは大きなファイルを管理することについての健全な意思決定を反映しています。

実際、多くのプロジェクトが大きなバイナリでGitが肥大化する問題に本当に苦しんでおり（実際で影響力のある問題）、Git LFS（または代替案）がその解決策です。リポジトリを管理可能に保ちながら大きなファイルを扱う—このため、Git LFSの理解、それが解決する問題、動作方法、そしていつ使うべきか対代替案はシニアレベルの価値ある知識です。大きなファイルを効果的に管理し、メディア、データ、または大型アセットを扱うプロジェクトに有用なトピックです。