Git LFS

Git is het de facto versiebeheersysteem geworden voor softwareontwikkelaars over de hele wereld. Dit open-source, gedistribueerde versiebeheersysteem is sneller dan zijn concurrenten. Het is gemakkelijk te gebruiken voor het aftakken en samenvoegen van code. Het heeft echter een prestatieprobleem met grote binaire bestanden. Git Large File Storage (LFS) is ontwikkeld om dit probleem aan te pakken.

Het probleem met grote bestanden in Git

Traditioneel zijn bepaalde bedrijven en instellingen weggebleven bij Git vanwege de inefficiëntie bij het verwerken van grote binaire bestanden. Ontwikkelaars van videogames en mediabedrijven hebben te maken met complexe texturen, full-motion video's en hoogwaardige audiobestanden. Onderzoeksinstituten moeten grote datasets bijhouden die gigabytes of terabytes kunnen zijn. Git heeft moeite met het onderhouden van deze grote bestanden.

Om het probleem te begrijpen, moeten we kijken hoe Git bestanden bijhoudt. Telkens wanneer er een commit is, maakt Git een objectknooppunt met een verwijzing naar zijn ouder of meerdere ouders. Het Git-gegevensmodel staat bekend als de gerichte acyclische graaf (DAG). Het DAG-model zorgt ervoor dat de ouder-kindrelatie nooit cycli kan vormen.

We kunnen de innerlijke werking van het DAG-model inspecteren. Hier is een voorbeeld van drie commits in een repository:

$ git log --oneline
2beb263 Commit C: afbeelding toegevoegd1.jpeg
866178e Vastleggen B: voeg b . toe.tekst
d48dd8b Commit A: voeg a . toe.tekst

In Commit A en B hebben we tekstbestand a . toegevoegd.txt en b.tekst. Vervolgens hebben we in Commit C een afbeeldingsbestand toegevoegd met de naam image1.jpeg. We kunnen de DAG als volgt visualiseren:

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

Als we de laatste commit inspecteren met het volgende commando:

$ git cat-file -p 2beb263
boom 7cc17ba5b041fb227b9ab5534d81bd836183a4e3
ouder 866178e37df64d9f19fa77c00d5ba9d3d4fc68f5
auteur Zak H 1513259427 -0800
committer Zak H 1513259427 -0800
Commit C: afbeelding toegevoegd1.jpeg

We kunnen zien dat Commit C (2beb263) Commit B (866178e) als ouder heeft. Als we nu het boomobject van Commit C (7cc17ba) inspecteren, kunnen we de blobs (binaire grote objecten) zien:

$ git cat-file -p 7cc17ba
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 een.tekst
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 b.tekst
100644 blob a44a66f9e06a8faf324d3ff3e11c9fa6966bfb56 afbeelding1.jpeg

We kunnen de grootte van de afbeeldingsblob controleren:

$ git cat-file -s a44a66f9e
871680

Git houdt de wijzigingen in deze boomstructuur bij. Laten we een wijziging aanbrengen in de afbeelding1.jpeg en controleer de geschiedenis:

$ git log --oneline
2e257db Commit D: gewijzigde afbeelding1.jpeg
2beb263 Commit C: afbeelding toegevoegd1.jpeg
866178e Vastleggen B: voeg b . toe.tekst
d48dd8b Commit A: voeg a . toe.tekst

Als we het Commit D-object (2e257db) controleren:

$ git cat-file -p 2e257db
boom 2405fad67610acf0f57b87af36f535c1f4f9ed0d
ouder 2beb263523725e1e8f9d96083140a4a5cd30b651
auteur Zak H 1513272250 -0800
committer Zak H 1513272250 -0800
Commit D: gewijzigde afbeelding1.jpeg

En de boom (2405fad) erin:

$ git cat-file -p 2405fad
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 een.tekst
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 b.tekst
100644 blob cb4a0b67280a92412a81c60df36a15150e713095 afbeelding1.jpeg

Merk op dat de SHA-1 hash voor image1.jpeg is veranderd. Het betekent dat het een nieuwe blob voor image1 heeft gemaakt.jpeg. We kunnen de grootte van de nieuwe blob controleren:

$ git cat-file -s cb4a0b6
1063696

Hier is een manier om de bovenstaande DAG-structuur te visualiseren:

Elk commit-object behoudt zijn eigen boom. Klodders worden in die boom gehouden. Git optimaliseert de ruimte door ervoor te zorgen dat het alleen de verschillen opslaat en compressie gebruikt voor opslag. Maar voor binaire bestandswijzigingen moet Git hele bestanden in de blobs opslaan omdat het moeilijk is om de verschillen te bepalen. Ook zijn beeld-, video- en audiobestanden al gecomprimeerd. Als gevolg hiervan eindigt de boom voor elke instantie van een gewijzigd binair bestand met een grote blob.

Laten we een voorbeeld bedenken waarbij we meerdere wijzigingen aanbrengen in een afbeeldingsbestand van 100 MB.

Elke keer dat we het bestand wijzigen, moet Git een blob van 100 MB maken. Dus pas na 3 commits is de Git-repository 300 MB. Je kunt zien dat de grootte van de Git-repository snel kan opblazen. Omdat Git een gedistribueerd versiebeheer is, ga je de hele repository downloaden naar je lokale instantie en veel met branches werken. Dus de grote blobs worden een prestatie-bottleneck.

De Git LFS lost het probleem op door de blobs te vervangen door lichtgewicht pointerfiles (PF) en een mechanisme te creëren om de blobs elders op te slaan.

Lokaal slaat Git de blobs op in de Git LFS-cache, en op afstand zal het ze opslaan in de Git LFS-winkel op GitHub of BitBucket.

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

Als je nu te maken hebt met de Git-repository, zullen de lichtgewicht PF-bestanden worden gebruikt voor de routinehandelingen. De blobs worden alleen opgehaald als dat nodig is. Als u bijvoorbeeld Commit C uitcheckt, zoekt Git LFS de PF3-aanwijzer op en downloadt Blob3. Dus de werkende repository zal slanker zijn en de prestaties zullen beter zijn. U hoeft zich geen zorgen te maken over de pointerfiles. Git LFS zal ze achter de schermen beheren.

Git LFS installeren en uitvoeren

Er zijn eerdere pogingen geweest om het probleem met de grote Git-bestanden op te lossen. Maar Git LFS is geslaagd omdat het gemakkelijk te gebruiken is. Je hoeft alleen maar LFS te installeren en het te vertellen welke bestanden moeten worden gevolgd.

Je kunt Git LFS installeren met de volgende commando's:

$ sudo apt-get install software-properties-common
$ curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash
$ sudo apt-get install git-lfs
$ git lfs install

Nadat je Git LFS hebt geïnstalleerd, kun je de gewenste bestanden volgen:

$ git lfs-track "*.jpeg"
Volgen "*.jpeg"

De uitvoer laat zien dat Git LFS de JPEG-bestanden volgt. Wanneer u begint met volgen met LFS, vindt u een: .gitattributes-bestand dat een vermelding bevat met de bijgehouden bestanden. De .gitattributes-bestand gebruikt dezelfde notatie als .gitignore-bestand. Hier is hoe de inhoud van .gitattributen ziet eruit:

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

U kunt ook zien welke bestanden worden bijgehouden met de volgende opdracht:

$ git lfs-track
Bijgehouden patronen weergeven
*.jpeg (.gitattributen)

Als u wilt stoppen met het volgen van een bestand, kunt u de volgende opdracht gebruiken:

$ git lfs untrack "*.jpeg"
Ontvolgen "*.jpeg"

Voor algemene Git-bewerkingen hoeft u zich geen zorgen te maken over LFS. Het zorgt automatisch voor alle backend-taken. Als je Git LFS eenmaal hebt ingesteld, kun je net als elk ander project aan de repository werken.

Verdere studie

Raadpleeg de volgende bronnen voor meer geavanceerde onderwerpen:

Git LFS-repository verplaatsen tussen hosts
Lokale Git LFS-bestanden verwijderen
Externe Git LFS-bestanden van de server verwijderen
Git LFS-website
Git LFS-documentatie

Referenties:

git-lfs.github.com: GitHub-opslagplaats
github.com/git-lfs/git-lfs/tree/master/docs: GitHub-documentatie voor Git LFS
atlassian.com/git/tutorials/git-lfs: Atlassian-zelfstudies
youtube.com: Wat is Git LFS
youtube.com: Grote bestanden bijhouden met Git LFS door Tim Pettersen, Atlassians
youtube.com: grote bestanden op de juiste opslag beheren met Git LFS, YouTube
youtube.com: Git Large File Storage - Werken met grote bestanden, YouTube
askubuntu.com/questions/799341: hoe-git-lfs-op-ubuntu-16-04 te installeren
github.com/git-lfs/git-lfs/blob/master/INSTALLEREN.md: Installatiehandleiding