Git LFS là gì và khi nào bạn cần nó?

Question

Accepted Answer

**Git LFS** (Large File Storage) là một extension để xử lý các **tệp binary lớn** (video, dataset, asset thiết kế, các binary lớn) một cách hiệu quả trong Git. Git được thiết kế cho văn bản/mã nguồn và xử lý các binary lớn kém, nên LFS lưu chúng riêng biệt trong khi giữ các tham chiếu nhẹ trong repository.

## Vấn đề: Git và các binary lớn

```text
Git lưu mọi phiên bản của mọi tệp trong lịch sử của nó (toàn bộ nội dung):
  → các tệp BINARY LỚN (video, dataset, PSD, binary lớn) làm phình repo ENORMOUSLY:
    - mỗi thay đổi lưu thêm một bản sao đầy đủ (binary không diff tốt)
    - repo và MỌI bản clone trở nên khổng lồ và chậm (clone/fetch tải toàn bộ lịch sử)
    - lịch sử không thể thu nhỏ dễ dàng (các blob lớn là vĩnh viễn)
→ Git tuyệt vời cho mã nguồn (văn bản, diff được), KÉM cho các binary lớn.
```

## Cách Git LFS hoạt động

```text
Git LFS thay thế các tệp lớn trong repo bằng các tệp POINTER nhỏ (một tham chiếu/hash),
và lưu các tệp lớn THỰC TẾ trên một server LFS riêng:
  → Git repo giữ nhỏ (chỉ các pointer trong lịch sử)
  → các tệp lớn thực tế được tải về theo nhu cầu (chỉ các phiên bản bạn cần)
→ Bạn làm việc bình thường; LFS hoán đổi trong suốt pointer ↔ tệp thực.
```

```bash
git lfs install                    # thiết lập LFS
git lfs track "*.psd"             # theo dõi một loại tệp với LFS (ghi vào .gitattributes)
git lfs track "*.mp4"
git add .gitattributes
# giờ các tệp lớn của các loại này tự động đi vào LFS (pointer trong Git)
git lfs ls-files                   # liệt kê các tệp được LFS theo dõi
```

## Khi nào dùng nó

```text
✓ Các repo với binary lớn: media (video/audio/ảnh), dataset, asset game,
  tệp thiết kế (PSD/Sketch), các sản phẩm biên dịch lớn, mô hình ML
✗ Các repo mã nguồn thuần không cần nó (Git xử lý văn bản tốt)
Các lựa chọn thay thế: đừng lưu các sản phẩm lớn trong Git chút nào (dùng artifact store, S3,
  package registry) — đôi khi là lựa chọn tốt hơn.
```

## Tại sao điều này quan trọng

Hiểu Git LFS là kiến thức cấp senior có giá trị để **xử lý các tệp binary lớn trong Git**, một vấn đề thực cho một số dự án, nên đó là kiến thức thực hành hữu ích.

Vấn đề cốt lõi là **Git xử lý các binary lớn kém**: vì Git lưu mọi phiên bản của mọi tệp trong lịch sử của nó và binary không diff tốt (mỗi thay đổi lưu thêm một bản sao đầy đủ), các tệp binary lớn (video, dataset, asset thiết kế, các sản phẩm lớn) **làm phình repository khổng lồ** — khiến repo và mọi bản clone khổng lồ và chậm, với sự phình to là vĩnh viễn và khó loại bỏ.

Đây là một vấn đề thực sự, đôi khi nghiêm trọng cho các dự án liên quan đến media, dataset, asset game, tệp thiết kế, hoặc mô hình ML. **Git LFS** giải quyết nó bằng cách lưu các tệp lớn **riêng biệt** (trên một server LFS) trong khi chỉ giữ các tệp **pointer** nhỏ trong lịch sử Git — nên repository giữ nhỏ và nhẹ, với các tệp lớn thực tế được tải về theo nhu cầu (chỉ các phiên bản cần).

Hiểu cách nó hoạt động (pointer trong Git, tệp thực trong LFS, hoán đổi trong suốt) và cách dùng nó (theo dõi các loại tệp qua `.gitattributes`) là kiến thức thực hành cho các dự án cần nó.

Quan trọng không kém là sự phán đoán về **khi nào dùng nó** (các repo với binary lớn) so với khi nó không cần thiết (mã nguồn thuần, nơi Git xử lý văn bản tốt) và sự nhận thức về các **lựa chọn thay thế** (đôi khi không lưu các sản phẩm lớn trong Git chút nào — dùng artifact store, S3, hoặc package registry — là lựa chọn tốt hơn).

Điều này phản ánh sự ra quyết định đúng đắn về quản lý các tệp lớn.

Vì một số dự án thực sự vật lộn với các binary lớn làm phình Git (một vấn đề thực, có ảnh hưởng), và vì Git LFS (hoặc các lựa chọn thay thế) là giải pháp — giữ các repo có thể quản lý được trong khi xử lý các tệp lớn — hiểu Git LFS, vấn đề nó giải quyết, cách nó hoạt động, và khi nào dùng nó so với các lựa chọn thay thế là kiến thức cấp senior có giá trị để quản lý các repository với các tệp lớn một cách hiệu quả, một chủ đề hữu ích cho các dự án xử lý media, dữ liệu, hoặc các asset lớn.