Git ist das De -facto -Versionskontrollsystem für Softwareentwickler auf der ganzen Welt geworden. Dieses Open-Source-Distributed-Versionskontrollsystem ist schneller als seine Konkurrenten. Es ist benutzerfreundlich für die Verzweigung und das Zusammenführen von Code. Es hat jedoch ein Leistungsproblem mit großen Binärdateien. Git Large Dateispeicher (LFS) wurde entwickelt, um dieses Problem anzugehen.
Das große Dateiproblem in Git
Traditionell sind bestimmte Unternehmen und Institutionen aufgrund der Ineffizienz bei großer Binärdateibehandlung von GIT ferngehalten. Videospielentwickler und Medienunternehmen müssen sich mit komplexen Texturen, Vollbewegungsvideos und hochwertigen Audiodateien befassen. Forschungsinstitute müssen große Datensätze im Auge behalten, die Gigabyte oder Terabyte sein können. Git hat Schwierigkeiten, diese großen Dateien aufrechtzuerhalten.
Um das Problem zu verstehen, müssen wir uns ansehen, wie Git die Dateien im Auge behält. Wann immer es ein Commit gibt, erstellt Git einen Objektknoten mit einem Zeiger auf seine Eltern oder mehrere Eltern. Das Git -Datenmodell ist als gerichteter Acyclic Graph (DAG) bekannt. Das DAG-Modell stellt sicher, dass die Eltern-zu-Kind-Beziehung niemals Zyklen bilden kann.
Wir können das Innenleben des DAG -Modells überprüfen. Hier ist ein Beispiel für drei Commits in einem Repository:
$ Git -Protokoll -Einmal
2beb263 Commit C: Image1 hinzugefügt1 hinzugefügt.JPEG
866178e Commit B: Hinzufügen B.txt
D48DD8B Commit a: Hinzufügen a.txt
In Commit A und B haben wir Textdatei a hinzugefügt.txt und b.txt. In Commit C haben wir dann eine Bilddatei namens Image1 hinzugefügt.JPEG. Wir können die DAG wie folgt visualisieren:
Commit C Commit B begehen a
2beb263 -> 866178e -> D48DD8B
Wenn wir den letzten Commit mit dem folgenden Befehl inspizieren:
$ git cat -file -p 2beb263
Tree 7CC17BA5B041FB227B9AB5534D81BD836183A4E3
Eltern 866178E37DF64D9F19FA77C00D5BA9D3D4FC68F5
Autor Zak H 1513259427 -0800
Kommitter Zak H 1513259427 -0800
Commit C: Image1 hinzugefügt1 hinzugefügt.JPEG
Wir können sehen, dass Commit C (2beb263) Commit B (866178e) als Elternteil hat. Wenn wir nun das Baumobjekt von Commit C (7cc17ba) inspizieren, können wir die Blobs (binäre große Objekte) sehen:
$ git cat -file -p 7cc17ba
100644 BLOB E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 A.txt
100644 BLOB E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 B.txt
100644 BLOB A44A66F9E06A8FAF324D3FF3E11C9FA6966BFB56 Image1.JPEG
Wir können die Größe des Bildblobs überprüfen:
$ git cat -file -s A44A66F9E
871680
Git verfolgt die Veränderungen in dieser Baumstruktur. Lassen Sie uns eine Änderung am Bild1 vornehmen.JPEG und überprüfen Sie die Geschichte:
$ Git -Protokoll -Einmal
2E257DB Commit D: Modified Image1.JPEG
2beb263 Commit C: Image1 hinzugefügt1 hinzugefügt.JPEG
866178e Commit B: Hinzufügen B.txt
D48DD8B Commit a: Hinzufügen a.txt
Wenn wir das Commit -D -Objekt (2E257DB) überprüfen:
$ git cat -file -p 2e257db
Tree 2405FAD67610ACF0F57B87AF36F535C1F4F9ED0D
Eltern 2BEB263523725E1E8F9D96083140A4A5CD30B651
Autor Zak H 1513272250 -0800
Kommitter Zak H 1513272250 -0800
Commit D: Modified Image1.JPEG
Und der Baum (2405fad) darin:
$ git cat -file -p 2405fad
100644 BLOB E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 A.txt
100644 BLOB E69DE29BB2D1D6434B8B29AE775AD8C2E48C5391 B.txt
100644 BLOB CB4A0B67280A92412A81C60DF36A15150E713095 Image1.JPEG
Beachten Sie, dass der SHA-1-Hash für Image1.JPEG hat sich verändert. Es bedeutet, dass es einen neuen Blob für Image1 erstellt hat.JPEG. Wir können die Größe des neuen Blob überprüfen:
$ git cat -file -s CB4A0B6
1063696
Hier finden Sie eine Möglichkeit, die obige DAG -Struktur zu visualisieren:
Commit D Commit C Commit B Commit a
| | | |
2e257db -> 2beb263 -> 866178e -> d48dd8b
| | | |
Tree4 Tree3 Tree2 Tree11
| | | |
Blobs Blobs Blobs Blobs
[/cce_c]
Jedes Commit -Objekt behält seinen eigenen Baum bei. In diesem Baum werden Blobs in diesem Baum gehalten. Git optimiert den Raum, indem sichergestellt wird, dass nur die Unterschiede gespeichert werden und die Komprimierung für die Speicherung verwendet. Bei Binärdateiänderungen muss Git jedoch ganze Dateien in den Blobs speichern, da es schwierig ist, die Unterschiede zu bestimmen. Auch Bild-, Video- und Audiodateien sind bereits komprimiert. Infolgedessen endet der Baum für jede Instanz einer modifizierten Binärdatei mit einem großen Blob.
Denken wir an ein Beispiel, in dem wir mehrere Änderungen an einer 100 -MB -Bilddatei vornehmen.
[cc width = "100%" height = "100%" entkommen = "True" thema = "Blackboard" nowrap = "0"]
Commit C -> Commit B -> Commit a
| | |
Tree3 Tree2 Tree1
| | |
Blob3 Blob2 Blob1
300 MB 200 MB 100 MB
[/cce_c]
Jedes Mal, wenn wir die Datei ändern, muss Git einen 100 -MB -Blob erstellen. Erst nach 3 Commits beträgt das Git -Repository 300 MB. Sie können sehen, dass die Größe des Git -Repositorys schnell in die Luft jagen kann. Da Git eine verteilte Versionskontrolle ist, werden Sie das gesamte Repository auf Ihre lokale Instanz herunterladen und viel mit Filialen arbeiten. Die großen Blobs werden also zu einem Performance -Engpass.
Das Git LFS löst das Problem, indem die Blobs durch leichte Zeigerdateien (PF) ersetzt und einen Mechanismus erstellt werden, um die Blobs an anderer Stelle zu speichern.
[cc width = "100%" height = "100%" entkommen = "True" thema = "Blackboard" nowrap = "0"]
Commit C -> Commit B -> Commit a
| | |
Tree3 Tree2 Tree1
| | |
PF3 PF2 PF1
[/cce_c]
Lokal Git speichert die Blobs im Git -LFS.
[cc width = "100%" height = "100%" entkommen = "True" thema = "Blackboard" nowrap = "0"]
PF1 -> Blob1
PF2 -> Blob2
PF3 -> Blob3
[/cce_bash]
Wenn Sie nun mit dem Git -Repository zu tun haben. Die Blobs werden nur bei Bedarf abgerufen. Wenn Sie beispielsweise CHOMPET C COMIT C COMMIT C haben, wird Git LFS den PF3 -Zeiger nachschlagen und Blob3 herunterladen. Das Arbeitsrepository wird also schlanker und die Leistung wird besser sein. Sie müssen sich keine Sorgen um die Zeigerdateien machen. Git LFS wird sie hinter den Kulissen verwalten.
Installieren und Ausführen von GIT -LFS
Es gab frühere Versuche, das Problem der Git Large Datei zu lösen. Aber Git LFS hat es geschafft, weil es einfach zu bedienen ist. Sie müssen nur LFS installieren und mitteilen, welche Dateien zu verfolgen sind.
Sie können GIT -LFS mit den folgenden Befehlen installieren:
[cc width = "100%" height = "100%" entkommen = "True" thema = "Blackboard" nowrap = "0"]
$ sudo apt-Get Installieren Sie Software-Properties-Common
$ curl -s https: // packagecloud.IO/Install/Repositories/Github/Git-LFS/Skript.Deb.Sh | sudo bash
$ sudo apt-Get Installieren Sie GIT-LFS
$ git lfs installieren
Sobald Sie Git LFS installiert haben, können Sie die gewünschten Dateien verfolgen:
$ git lfs track "*.JPEG "
Verfolgung "*.JPEG "
Die Ausgabe zeigt Ihnen, dass Git LFS die JPEG -Dateien verfolgt. Wenn Sie mit der Verfolgung mit LFS beginnen, finden Sie eine .GitatTtributes -Datei mit einem Eintrag, der die verfolgten Dateien zeigt. Der .Die Datei gitatTributes verwenden dieselbe Notation wie .Gitignore -Datei. So ist der Inhalt von .Gitattributes sieht aus:
$ cat .Gitattributes
*.JPEG Filter = LFS Diff = LFS merge = lfs -text
Sie können auch feststellen, welche Dateien mit dem folgenden Befehl verfolgt werden:
$ Git LFS Track
Listing verfolgte Muster
*.JPEG (.GitatTtributes)
Wenn Sie die Verfolgung einer Datei nicht mehr verfolgen möchten, können Sie den folgenden Befehl verwenden:
$ git lfs untrack "*.JPEG "
Ungefangene "*.JPEG "
Für allgemeine GIT -Operationen müssen Sie sich keine Sorgen um LFS machen. Es wird sich automatisch um alle Backend -Aufgaben kümmern. Sobald Sie Git LFS eingerichtet haben, können Sie wie jedes andere Projekt am Repository arbeiten.
Weiteres Studium
Weitere weiteren Themen finden Sie in den folgenden Ressourcen:
- Verschieben von Git LFS -Repository zwischen Hosts
- Löschen lokaler Git -LFS -Dateien
- Entfernen Sie Remote -Git -LFS -Dateien vom Server
- Git LFS -Website
- Git LFS -Dokumentation
Verweise:
- Git-LFS.Github.com: github repo
- Github.com/git-lfs/git-lfs/baum/master/docs: GitHub-Dokumentation für Git LFS
- Atlassian.Com/Git/Tutorials/Git-LFS: Atlassian Tutorials
- Youtube.com: Was ist Git LFS
- Youtube.com: Verfolgung großer Dateien mit Git LFS von Tim Pettersen, Atlassian
- Youtube.COM: Verwalten Sie riesige Dateien auf dem richtigen Speicher mit Git LFS, YouTube
- Youtube.Com: Git Large Dateispeicher - wie man mit großen Dateien arbeitet, YouTube
- Github.com/git-lfs/git-lfs/blob/master/installieren.MD: Installationshandbuch