რა არის 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 ისტორიაში მხოლოდ პატარა **მაჩვენებელი ფაილები** ნიშნავს — ამ წყალობით რეპოზიტორია პატარა და მცირე რჩება, ხოლო დიდი ფაილები მოთხოვნით ჩამოიტვირთება (მხოლოდ საჭირო ვერსიები).

იმის გაცნობა, თუ როგორ მუშაობს (მაჩვენებელი Git-ში, რეალური ფაილები LFS-ში, გამჭვირვალე ჩანაცვლება) და როგორ გამოიყენოთ (ფაილის ტიპები `.gitattributes`-ის საშუალებით) არის პრაქტიკული ცოდნა პროექტებისთვის, რომლებიც მას საჭიროებენ.

თანაბრად მნიშვნელოვანი არის მსჯელობა იმის შესახებ, **როდის გამოიყენოთ ის** (რეპოზიტორია დიდი ბინარული ფაილებით) სახელმწიფო სალაპარაკო დროს, როდესაც ის უსიამოვნე (სუფთა წყაროს კოდი, სადაც Git კარგად ითხოვს ტექსტს) და ცნობიერება **ალტერნატივების** შესახებ (ზოგჯერ დიდი არტიფაქტების Git-ში ნაკლებად შენახვა ბუნებრივი არჩევანია — ის გამოიყენებს არტიფაქტის მაცივრებს, S3-ს ან პაკეტის რეგისტრებს — უკეთესი არჩევანი).

ეს ასახავს ჯანსაღ გადაწყვეტილებას დიდი ფაილების მართვის შესახებ.

ვინაიდან ზოგიერთი პროექტი სინამდვილეში ებრძვის დიდი ბინარული ფაილებით Git-ის ზეწოლას (რეალური, გავლენის მქონე პრობლემა), და რადგან Git LFS (ან ალტერნატივები) გამოსავალია — რეპოზიტორია მართლიანი ინარჩუნოს დიდი ფაილების დამუშავების დროს — Git LFS-ის გაცნობა, პრობლემა რომელსაც ის სწორავს, როგორ მუშაობს და როდის გამოიყენოთ ის ალტერნატივებთან შედარებით ღირებული უმცროსი დონის ცოდნაა დიდი ფაილების შემცველი რეპოზიტორიებს ეფექტურად მართვის, მსმენელი თემა მედია, მონაცემი ან დიდი აქტივებთან მუშაობის დროს.