So prüfen Sie, ob ein Git-Repository LFS verwendet

Einführung

In diesem Lab lernen Sie, wie Sie feststellen können, ob ein Git-Repository Git Large File Storage (LFS) nutzt. Wir werden die wichtigsten Indikatoren für die Verwendung von LFS untersuchen, beginnend mit der Prüfung der .gitattributes-Datei, die für die Konfiguration der LFS-Verfolgung von entscheidender Bedeutung ist.

Anschließend verwenden Sie den Befehl git lfs env, um die LFS-Umgebung und die Einstellungen innerhalb des Repositorys zu überprüfen. Abschließend werden wir mit LFS-verfolgten Dateien testen, um sicherzustellen, dass LFS wie erwartet die Verwaltung großer Dateien übernimmt. Dieser praktische Ansatz vermittelt Ihnen die Fähigkeiten, um die Integration von LFS in Ihren Git-Projekten zu erkennen und zu verstehen.

Skills Graph

Prüfen auf die .gitattributes-Datei

In diesem Schritt werden wir untersuchen, wie Git LFS eine spezielle Datei namens .gitattributes verwendet, um große Dateien zu verfolgen. Diese Datei teilt Git mit, welche Dateien von LFS behandelt werden sollen, anstatt direkt im Git-Repository gespeichert zu werden.

Zunächst stellen wir sicher, dass wir uns im Projektverzeichnis befinden. Öffnen Sie Ihr Terminal und geben Sie ein:

cd ~/project/my-time-machine

Jetzt erstellen wir eine Platzhalterdatei, die wir später Git LFS zum Verfolgen geben werden. Wir nennen sie large_image.png.

echo "This is a large image file placeholder." > large_image.png

Dieser Befehl erstellt eine Datei namens large_image.png und fügt etwas Text hinein. In einer realen Situation würde dies eine große Binärdatei wie ein Bild, ein Video oder ein Archiv sein.

Als Nächstes müssen wir Git LFS mitteilen, dass es diese Art von Dateien verfolgen soll. Wir tun dies mit dem Befehl git lfs track. Dieser Befehl erstellt oder aktualisiert auch automatisch die .gitattributes-Datei in Ihrem Repository.

git lfs track "*.png"

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

Tracking "*.png"

Dieser Befehl teilt Git LFS mit, dass es alle Dateien mit der .png-Erweiterung verfolgen soll. Er fügt auch einen Eintrag in die .gitattributes-Datei hinzu.

Jetzt schauen wir uns den Inhalt der .gitattributes-Datei an, um zu sehen, was hinzugefügt wurde.

cat .gitattributes

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

*.png filter=lfs diff=lfs merge=lfs -text

Diese Zeile in der .gitattributes-Datei ist das Geheimnis, das Git anweist, LFS für .png-Dateien zu verwenden. Sie gibt an, dass Git für Dateien, die dem Muster *.png entsprechen, den lfs-Filter für das Vergleichen, Zusammenführen und Speichern anwenden soll. Der -text-Teil stellt sicher, dass Git nicht versucht, Binärdateien als Text zu behandeln.

Das Verständnis der .gitattributes-Datei ist der Schlüssel für die effektive Verwendung von Git LFS. So konfigurieren Sie, welche Arten von großen Dateien von LFS verwaltet werden, und halten so Ihr Haupt-Git-Repository klein und schnell.

Ausführen von git lfs env zur Überprüfung von LFS

In diesem Schritt verwenden wir den Befehl git lfs env, um die Git LFS-Umgebung zu prüfen und sicherzustellen, dass sie korrekt in unserem Repository eingerichtet ist. Dieser Befehl liefert nützliche Informationen über die Installation und Konfiguration von Git LFS.

Stellen Sie sicher, dass Sie sich immer noch im Projektverzeichnis befinden:

cd ~/project/my-time-machine

Jetzt führen Sie den Befehl git lfs env aus:

git lfs env

Sie sollten eine Ausgabe ähnlich der folgenden sehen (die genaue Ausgabe kann je nach Git LFS-Version und Systemkonfiguration geringfügig variieren):

git-lfs/3.x.x (Linux; zsh)
git version 2.34.1

Endpoint=
  https://github.com/labex/my-time-machine.git/info/lfs (auth=none)
Endpoint (SSH)=
  [email protected]:labex/my-time-machine.git/info/lfs (auth=none)

LocalWorkingDir=/home/labex/project/my-time-machine
LocalGitDir=/home/labex/project/my-time-machine/.git
LocalGitStorageDir=/home/labex/project/my-time-machine/.git/lfs
LocalMediaDir=/home/labex/project/my-time-machine/.git/lfs/objects
LocalRecentObjectsDir=/home/labex/project/my-time-machine/.git/lfs/objects/sha256/recent
LocalRecentObjectsLogDir=/home/labex/project/my-time-machine/.git/lfs/objects/sha256/recent/logs
LocalTmpDir=/home/labex/project/my-time-machine/.git/lfs/tmp
LocalTriggers=

Disk space utilization:
  du -s -h .git/lfs
  4.0K    .git/lfs

Git LFS initialized.

Diese Ausgabe liefert viele Informationen, darunter:

• Die verwendete Version von Git LFS.
• Die verwendete Version von Git.
• Die LFS-Endpunkte (wo LFS-Dateien hoch- oder heruntergeladen würden, obwohl wir in diesem Lab kein Remote-Repository verwenden).
• Die lokalen Verzeichnisse, in denen Git LFS seine Daten innerhalb des .git-Verzeichnisses speichert.
• Die Speicherplatzauslastung durch LFS-Objekte (derzeit sehr gering, da wir noch keine großen Dateien hinzugefügt haben).
• Bestätigung, dass Git LFS in diesem Repository initialisiert ist.

Das Ausführen von git lfs env ist eine gute Möglichkeit, schnell zu überprüfen, ob Git LFS in Ihrem aktuellen Repository installiert und korrekt konfiguriert ist. Es hilft Ihnen zu verstehen, wo LFS seine Daten speichert und bestätigt, dass die erforderlichen Hooks und Filter vorhanden sind.

Test mit von LFS verfolgten Dateien

In diesem letzten Schritt fügen wir die von LFS verfolgte Datei in die Git-Staging-Area ein und committen sie. Dies zeigt, wie Git LFS die Datei anders behandelt als normale Dateien.

Zunächst stellen Sie sicher, dass Sie sich im richtigen Verzeichnis befinden:

cd ~/project/my-time-machine

Wir haben bereits die Datei large_image.png erstellt und in den vorherigen Schritten Git LFS so konfiguriert, dass es .png-Dateien verfolgt. Jetzt fügen wir die Datei mit git add in die Staging-Area ein:

git add large_image.png

Dieser Befehl bringt die Datei für den nächsten Commit in die Staging-Area. Git LFS unterbricht diesen Vorgang für large_image.png, da sie dem Muster in .gitattributes entspricht. Anstatt den gesamten Dateiinhalt in den Git-Index hinzuzufügen, fügt Git LFS eine kleine "Zeigerdatei" hinzu.

Lassen Sie uns den Status überprüfen, um die in die Staging-Area eingestellte Datei zu sehen:

git status

Sie sollten eine Ausgabe sehen, die anzeigt, dass large_image.png eine neue Datei ist, die bereit zum Committen ist:

On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   .gitattributes
        new file:   large_image.png

Beachten Sie, dass .gitattributes ebenfalls in die Staging-Area eingestellt ist, da wir es in Schritt 1 geändert haben.

Jetzt committen wir die Änderungen:

git commit -m "Add LFS tracked image placeholder"

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

[master (root-commit) abcdefg] Add LFS tracked image placeholder
 2 files changed, X insertions(+)
 create mode 100644 .gitattributes
 create mode 100644 large_image.png

Die Commit-Nachricht bestätigt, dass sowohl .gitattributes als auch large_image.png committet wurden. Der eigentliche Inhalt von large_image.png wird jedoch nicht direkt im Git-Commit gespeichert. Stattdessen speichert der Commit die kleine Zeigerdatei, und der Inhalt der großen Datei wird von Git LFS verwaltet.

Um den Unterschied zu sehen, schauen wir uns den Inhalt der Datei an, wie er in Git gespeichert ist, mit git show. Dieser Befehl zeigt den Inhalt einer Datei bei einem bestimmten Commit an.

git show HEAD:large_image.png

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

version https://git-lfs.github.com/spec/v1
oid sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
size 31

Dies ist der Inhalt der Zeigerdatei, nicht der eigentliche Text "This is a large image file placeholder.". Dies zeigt, dass Git einen Verweis auf die große Datei speichert, während Git LFS den eigentlichen Dateiinhalt verwaltet.

Dies ist das Kernkonzept von Git LFS: Das Haupt-Git-Repository wird leichtgewichtig gehalten, indem nur Zeiger auf große Dateien gespeichert werden, während der Inhalt der großen Dateien separat gespeichert wird.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man prüft, ob ein Git-Repository Git LFS (Large File Storage) verwendet. Wir haben zunächst die Rolle der .gitattributes-Datei verstanden, die für die Konfiguration von Git LFS von entscheidender Bedeutung ist. Wir haben eine Testdatei erstellt und git lfs track verwendet, um Git LFS anzuweisen, Dateien mit einer bestimmten Dateierweiterung zu verwalten. Dabei haben wir beobachtet, wie dieser Befehl die .gitattributes-Datei automatisch mit der erforderlichen Konfiguration aktualisiert. Anschließend haben wir den Inhalt der .gitattributes-Datei untersucht, um den Eintrag zu sehen, der von git lfs track hinzugefügt wurde, und die Bedeutung der Attribute filter=lfs, diff=lfs, merge=lfs und -text verstanden.

Wir haben auch den Befehl git lfs env als weitere Methode zur Überprüfung der Anwesenheit und Konfiguration von Git LFS in einem Repository untersucht. Dieser Befehl liefert detaillierte Informationen über die Git LFS-Umgebung, einschließlich der Version, der Repository-Einstellungen und der verfolgten Dateimuster, und bietet einen umfassenden Überblick darüber, wie LFS eingerichtet ist. Schließlich haben wir gelernt, wie man das LFS-Tracking testet, indem man eine Datei hinzufügt und committet, die dem konfigurierten Muster entspricht, und so bestätigt, dass Git LFS die große Datei korrekt behandelt, anstatt ihren gesamten Inhalt im Haupt-Git-Repository zu speichern.