ما هو 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 يخزن كل نسخة من كل ملف في سجله التاريخي والملفات الثنائية لا تتعارض بشكل جيد (كل تغيير يخزن نسخة كاملة أخرى)، فإن الملفات الثنائية الكبيرة (مقاطع الفيديو والمجموعات البيانية وموارد التصميم والقطع الكبيرة) **تضخم المستودع بشكل هائل** — مما يجعل المستودع وكل نسخة منه ضخمة وبطيئة، مع كون التضخم دائماً وصعب الإزالة.

هذه مشكلة حقيقية وأحياناً خطيرة للمشاريع التي تتضمن وسائط أو مجموعات بيانات أو موارد الألعاب أو ملفات التصميم أو نماذج التعلم الآلي. **Git LFS** يحلها بتخزين الملفات الكبيرة **بشكل منفصل** (على خادم LFS) مع الاحتفاظ فقط بـ **ملفات مؤشر** صغيرة في سجل Git — بذلك يبقى المستودع صغيراً وخفيف الوزن، مع تحميل الملفات الكبيرة عند الحاجة (فقط الإصدارات المطلوبة).

فهم كيفية عمله (المؤشرات في Git والملفات الحقيقية في LFS والتبديل الشفاف) وكيفية استخدامه (تتبع أنواع الملفات عبر `.gitattributes`) هو المعرفة العملية للمشاريع التي تحتاجها.

الأهمية نفسها لها الحكم حول **متى تستخدمه** (المستودعات ذات الملفات الثنائية الكبيرة) مقابل عدم الحاجة إليه (الكود النقي المصدري، حيث يتعامل Git بشكل جيد مع النصوص) والوعي بـ **البدائل** (أحياناً عدم تخزين القطع الكبيرة في Git على الإطلاق — باستخدام متاجر القطع أو S3 أو سجلات الحزم — هو الخيار الأفضل).

هذا يعكس اتخاذ قرارات سليمة بشأن إدارة الملفات الكبيرة.

بما أن بعض المشاريع تواجه حقاً مشاكل في تضخم الملفات الثنائية الكبيرة في Git (مشكلة حقيقية وذات تأثير)، وحيث أن Git LFS (أو البدائل) هو الحل — الحفاظ على المستودعات قابلة للإدارة مع التعامل مع الملفات الكبيرة — فإن فهم Git LFS ومشكلة التي يحلها وكيفية عمله ومتى يتم استخدامه مقابل البدائل هو معرفة قيّمة على مستوى كبار المطورين لإدارة المستودعات ذات الملفات الكبيرة بشكل فعال، وهو موضوع مفيد للمشاريع التي تتعامل مع الوسائط أو البيانات أو الموارد الكبيرة.