Git LFS

Git se stal de facto systémem pro správu verzí pro vývojáře softwaru po celém světě. Tento open-source systém distribuované správy verzí je rychlejší než jeho konkurenti. Je snadno použitelný pro větvení a slučování kódu. Má však problém s výkonem u velkých binárních souborů. K řešení tohoto problému bylo vyvinuto úložiště Git Large File Storage (LFS).

Problém velkých souborů v Gitu

Některé společnosti a instituce se tradičně od Gitu držely dál kvůli neefektivnosti zpracování velkých binárních souborů. Vývojáři videoher a mediální společnosti se musí vypořádat se složitými texturami, plně pohyblivými videi a vysoce kvalitními zvukovými soubory. Výzkumné ústavy musí sledovat velké datové soubory, které mohou být gigabajty nebo terabajty. Git má potíže s udržováním těchto velkých souborů.

Abychom tomuto problému porozuměli, musíme se podívat na to, jak Git sleduje soubory. Kdykoli existuje potvrzení, Git vytvoří uzel objektu s ukazatelem na jeho rodiče nebo více rodičů. Datový model Git je známý jako směrovaný acyklický graf (DAG). Model DAG zajišťuje, že vztah rodič-dítě nemůže nikdy vytvářet žádné cykly.

Můžeme zkontrolovat vnitřní fungování modelu DAG. Zde je příklad tří revizí v úložišti:

$ git log - online
2beb263 Commit C: přidán obrázek 1.jpeg
866178e Commit B: add b.txt
d48dd8b Commit A: přidat a.txt

Ve Commit A a B jsme přidali textový soubor a.txt a b.txt. Pak jsme do Commit C přidali obrazový soubor s názvem image1.jpeg. DAG můžeme vizualizovat takto:

Potvrdit C Potvrdit B Potvrdit A
2beb263 -> 866178e -> d48dd8b

Pokud zkontrolujeme poslední potvrzení s následujícím příkazem:

$ git cat-file -p 2beb263
strom 7cc17ba5b041fb227b9ab5534d81bd836183a4e3
nadřazený 866178e37df64d9f19fa77c00d5ba9d3d4fc68f5
autor Zak H 1513259427-0800
účastník Zak H 1513259427-0800
Potvrdit C: přidán obrázek 1.jpeg

Vidíme, že Commit C (2beb263) má Commit B (866178e) jako nadřazený. Nyní, když zkontrolujeme objekt stromu Commit C (7cc17ba), můžeme vidět objekty BLOB (binární velké objekty):

$ git cat-file -p 7cc17ba
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a.txt
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 b.txt
100644 blob a44a66f9e06a8faf324d3ff3e11c9fa6966bfb56 obrázek1.jpeg

Můžeme zkontrolovat velikost objektu blob obrázku:

$ git cat-file -s a44a66f9e
871680

Git sleduje změny v této stromové struktuře. Udělejme úpravu image1.jpeg a zkontrolovat historii:

$ git log - online
2e257db Commit D: upravený obrázek 1.jpeg
2beb263 Commit C: přidán obrázek 1.jpeg
866178e Commit B: add b.txt
d48dd8b Commit A: přidat a.txt

Pokud zkontrolujeme objekt Commit D (2e257db):

$ git cat-file -p 2e257db
strom 2405fad67610acf0f57b87af36f535c1f4f9ed0d
nadřazený objekt 2beb263523725e1e8f9d96083140a4a5cd30b651
autor Zak H 1513272250-0800
účastník Zak H 1513272250-0800
Potvrdit D: upravený obrázek 1.jpeg

A strom (2405fad) uvnitř:

$ git cat-file -p 2405fad
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a.txt
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 b.txt
100644 blob cb4a0b67280a92412a81c60df36a15150e713095 obrázek 1.jpeg

Všimněte si, že SHA-1 hash pro image1.jpeg se změnil. To znamená, že vytvořil nový objekt blob pro image1.jpeg. Můžeme zkontrolovat velikost nového objektu blob:

$ git cat-file -s cb4a0b6
1063696

Zde je způsob, jak vizualizovat výše uvedenou strukturu DAG:

Každý objekt odevzdání udržuje svůj vlastní strom. Bloby jsou udržovány uvnitř tohoto stromu. Git optimalizuje prostor tím, že zajišťuje, že ukládá pouze rozdíly a pro ukládání používá kompresi. Ale pro změny binárních souborů musí Git ukládat celé soubory do objektů blob, protože je obtížné určit rozdíly. Také obrazové, obrazové a zvukové soubory jsou již komprimovány. Výsledkem je, že strom pro každou instanci upraveného binárního souboru končí velkým blobem.

Uvažujme o příkladu, kde provádíme více změn v obrazovém souboru 100 MB.

Pokaždé, když soubor změníme, musí Git vytvořit 100 MB blob. Takže až po 3 provizích má úložiště Git 300 MB. Vidíte, že velikost úložiště Git může rychle vybuchnout. Protože Git je řízení distribuované verze, budete stahovat celé úložiště do místní instance a hodně pracovat s větvemi. Takže velké objekty BLOB se stávají překážkou výkonu.

Git LFS řeší problém nahrazením objektů blob soubory lehkého ukazatele (PF) a vytvořením mechanismu pro uložení objektů blob jinde.

Lokálně Git ukládá objekty blob do mezipaměti Git LFS a na dálku je bude ukládat do úložiště Git LFS na GitHub nebo BitBucket.

PF1 -> Blob1
PF2 -> Blob2
PF3 -> Blob3

Nyní, když máte co do činění s úložištěm Git, budou pro rutinní operace použity lehké soubory PF. Bloby budou načteny pouze v případě potřeby. Například pokud zapíšete Commit C, pak Git LFS vyhledá ukazatel PF3 a stáhne Blob3. Takže pracovní úložiště bude štíhlejší a výkon bude lepší. Nemusíte si dělat starosti se soubory ukazatelů. Git LFS je bude spravovat v zákulisí.

Instalace a spuštění Git LFS

Byl zde předchozí pokus o vyřešení problému s velkým souborem Git. Ale Git LFS uspěl, protože je snadno použitelný. Musíte jen nainstalovat LFS a říct mu, které soubory chcete sledovat.

Git LFS můžete nainstalovat pomocí následujících příkazů:

$ sudo apt-get install software-properties-common
$ curl -s https: // balíčekcloud.io / install / repositories / github / git-lfs / skript.deb.sh | sudo bash
$ sudo apt-get nainstalovat git-lfs
$ git lfs instalace

Jakmile si nainstalujete Git LFS, můžete sledovat požadované soubory:

$ git lfs track "*.jpeg "
Sledování "*.jpeg "

Výstup ukazuje, že Git LFS sleduje soubory JPEG. Když začnete sledovat pomocí LFS, najdete a .soubor gitattributes, který bude mít záznam zobrazující sledované soubory. The .soubor gitattributes používá stejný zápis jako .soubor gitignore. Zde je, jak je obsah .gitattributes vypadá:

$ kat .gitattributy
*.jpeg filter = lfs diff = lfs merge = lfs -text

Můžete také zjistit, které soubory jsou sledovány, pomocí následujícího příkazu:

$ git lfs stopa
Výpis sledovaných vzorů
*.jpeg (.gitattributes)

Pokud chcete zastavit sledování souboru, můžete použít následující příkaz:

$ git lfs untrack "*.jpeg "
Rozbalení "*.jpeg "

U obecných operací Git se nemusíte starat o LFS. Automaticky se postará o všechny back-endové úlohy. Jakmile nastavíte Git LFS, můžete pracovat v úložišti jako každý jiný projekt.

Další studie

Podrobnější témata najdete v následujících zdrojích:

Přesouvání úložiště Git LFS mezi hostiteli
Mazání místních souborů Git LFS
Odebrání vzdálených souborů Git LFS ze serveru
Web Git LFS
Dokumentace Git LFS

Reference:

git-lfs.github.com: GitHub repo
github.com / git-lfs / git-lfs / tree / master / docs: Dokumentace GitHub pro Git LFS
atlassian.com / git / tutorials / git-lfs: Atlassian Tutorials
Youtube.com: Co je to Git LFS
Youtube.com: Sledování obrovských souborů pomocí Git LFS, Tim Pettersen, Atlassian
Youtube.com: Správa obrovských souborů na správném úložišti pomocí Git LFS, YouTube
Youtube.com: Git Large File Storage - Jak pracovat s velkými soubory, YouTube
askubuntu.com / questions / 799341: jak nainstalovat git-lfs-on-ubuntu-16-04
github.com / git-lfs / git-lfs / blob / master / INSTALACE.md: Instalační příručka