Git LFS คืออะไรและคุณต้องการมันเมื่อใด?

Question

Accepted Answer

**Git LFS** (Large File Storage) เป็นส่วนขยายสำหรับการจัดการ**ไฟล์ binary ขนาดใหญ่** (วิดีโอ, dataset, ไฟล์ design, binary ขนาดใหญ่) อย่างมีประสิทธิภาพใน Git Git ถูกออกแบบมาสำหรับ text/source code และจัดการ binary ขนาดใหญ่ได้ไม่ดี ดังนั้น LFS จึงเก็บมันแยกต่างหากในขณะที่เก็บการอ้างอิงที่เบาไว้ใน repository

## ปัญหา: Git กับ binary ขนาดใหญ่

```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 ที่มีคุณค่าต่อ**การจัดการไฟล์ binary ขนาดใหญ่ใน Git** ซึ่งเป็นปัญหาจริงสำหรับบางโปรเจกต์ จึงเป็นความรู้เชิงปฏิบัติที่มีประโยชน์

ประเด็นหลักคือ **Git จัดการ binary ขนาดใหญ่ได้ไม่ดี**: เพราะ Git เก็บทุกเวอร์ชันของทุกไฟล์ในประวัติและ binary diff ได้ไม่ดี (แต่ละการเปลี่ยนแปลงเก็บสำเนาเต็มอีกชุด) ไฟล์ binary ขนาดใหญ่ (วิดีโอ, dataset, ไฟล์ design, artifact ขนาดใหญ่) **ทำให้ repository บวมอย่างมหาศาล** — ทำให้ repo และทุก clone ใหญ่และช้า โดยความบวมนั้นถาวรและยากที่จะลบออก

นี่เป็นปัญหาที่แท้จริงและบางครั้งร้ายแรงสำหรับโปรเจกต์ที่เกี่ยวกับมีเดีย, dataset, game asset, ไฟล์ design หรือ ML model **Git LFS** แก้ปัญหานี้โดยเก็บไฟล์ขนาดใหญ่**แยกต่างหาก** (บน LFS server) ในขณะที่เก็บเพียง **pointer file** เล็ก ๆ ในประวัติ Git — ดังนั้น repository จึงเล็กและเบา โดยไฟล์ขนาดใหญ่จริงถูกดาวน์โหลดตามต้องการ (เฉพาะเวอร์ชันที่ต้องการ)

การเข้าใจว่ามันทำงานอย่างไร (pointer ใน Git, ไฟล์จริงใน LFS, การสลับแบบโปร่งใส) และวิธีใช้ (การ track ประเภทไฟล์ผ่าน `.gitattributes`) เป็นความรู้เชิงปฏิบัติสำหรับโปรเจกต์ที่ต้องการมัน

ที่สำคัญเท่ากันคือวิจารณญาณเรื่อง**เมื่อใดควรใช้** (repo ที่มี binary ขนาดใหญ่) เทียบกับเมื่อไม่จำเป็น (source code ล้วน ที่ Git จัดการ text ได้ดี) และการตระหนักถึง**ทางเลือก** (บางครั้งการไม่เก็บ artifact ขนาดใหญ่ใน Git เลย — ใช้ artifact store, S3 หรือ package registry — เป็นทางเลือกที่ดีกว่า)

สิ่งนี้สะท้อนการตัดสินใจที่ดีเกี่ยวกับการจัดการไฟล์ขนาดใหญ่

เนื่องจากบางโปรเจกต์ประสบปัญหาจริงกับ binary ขนาดใหญ่ที่ทำให้ Git บวม (เป็นปัญหาจริงที่ส่งผลกระทบ) และเนื่องจาก Git LFS (หรือทางเลือก) เป็นวิธีแก้ — รักษา repo ให้จัดการได้ในขณะที่จัดการไฟล์ขนาดใหญ่ — การเข้าใจ Git LFS, ปัญหาที่มันแก้, วิธีทำงาน และเมื่อใดควรใช้เทียบกับทางเลือก จึงเป็นความรู้ระดับ senior ที่มีคุณค่าต่อการจัดการ repository ที่มีไฟล์ขนาดใหญ่อย่างมีประสิทธิภาพ เป็นหัวข้อที่มีประโยชน์สำหรับโปรเจกต์ที่เกี่ยวข้องกับมีเดีย, ข้อมูล หรือ asset ขนาดใหญ่