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 ہر فائل کے ہر ورژن کو اپنی تاریخ میں محفوظ کرتا ہے اور بائنریز اچھی طریقے سے فرق نہیں کرتے (ہر تبدیلی ایک اور مکمل کاپی محفوظ کرتی ہے)، بڑی بائنری فائلیں (ویڈیوز، ڈیٹاسیٹس، ڈیزائن ایسٹس، بڑے آرٹیفیکٹس) **ریپوزٹری کو بہت بڑھاتی ہیں** — ریپوزٹری اور ہر کلون کو بہت بڑا اور سست بناتی ہے، یہ بڑھتی ہوئی ہمیشہ کے لیے مستقل ہے اور ہٹانا مشکل ہے۔

یہ میڈیا، ڈیٹاسیٹس، گیم ایسٹس، ڈیزائن فائلوں، یا ML ماڈلز سے متعلق پروجیکٹس کے لیے ایک حقیقی، کبھی کبھی سنگین مسئلہ ہے۔ **Git LFS** اسے بڑی فائلوں کو **الگ طریقے سے** (ایک LFS سرور پر) محفوظ کر کے حل کرتا ہے جبکہ Git کی تاریخ میں صرف چھوٹی **pointer فائلیں** رکھتا ہے — اس طرح ریپوزٹری چھوٹا اور ہلکا رہتا ہے، اصل بڑی فائلیں درخواست پر ڈاؤن لوڈ ہوتی ہیں (صرف ضرورت کے ورژنز)۔

یہ سمجھنا کہ یہ کیسے کام کرتا ہے (Git میں pointers، LFS میں حقیقی فائلیں، شفاف تبدیلی) اور اسے کیسے استعمال کریں (.gitattributes کے ذریعے فائل کی اقسام کو ٹریک کریں) ان پروجیکٹس کے لیے عملی علم ہے جنہیں اس کی ضرورت ہے۔

یکساں طور پر اہم **کب اسے استعمال کریں** (بڑی بائنریز والے repos) بمقابلہ جب یہ غیر ضروری ہو (خالص سورس کوڈ، جہاں Git متن کو اچھی طریقے سے سنبھالتا ہے) اس بارے میں فیصلہ ہے اور **متبادل** کے بارے میں شعور (کبھی کبھی بڑے آرٹیفیکٹس کو Git میں محفوظ نہ کرنا بالکل — artifact stores، S3، یا package registries استعمال کرنا — بہتر انتخاب ہے)۔

یہ بڑی فائلوں کو منظم کرنے کے بارے میں صحیح فیصلہ سازی کو ظاہر کرتا ہے۔

چونکہ کچھ پروجیکٹس واقعی بڑی بائنریز سے Git میں پھیلاؤ کے ساتھ جدوجہد کرتے ہیں (ایک حقیقی، اثر انگیز مسئلہ)، اور چونکہ Git LFS (یا متبادل) حل ہے — repos کو قابل انتظام رکھتے ہوئے بڑی فائلوں کو سنبھالنا — Git LFS کو سمجھنا، یہ مسئلہ جو حل کرتا ہے، یہ کیسے کام کرتا ہے، اور کب اسے متبادل کے مقابلے میں استعمال کریں یہ بڑی فائلوں والے ریپوزٹریز کو مؤثر طریقے سے منظم کرنے کے لیے سینئر سطح کا قیمتی علم ہے، میڈیا، ڈیٹا، یا بڑے ایسٹس سے نمٹنے والے پروجیکٹس کے لیے ایک مفید موضوع ہے۔