Verwalten und Speichern großer Dateien in Git

  • Artikel
  • 5 Minuten Lesedauer

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Git ist großartig, den Fußabdruck Ihres Quellcodes klein zu halten, da die Unterschiede zwischen Versionen einfach ausgewählt und Code einfach komprimiert werden. Große Dateien, die nicht gut komprimieren und zwischen Versionen (z. B. Binärdateien) vollständig komprimieren, stellen Probleme beim Speichern in Ihrem Git-Repos dar. Gits schnelle Leistung stammt aus der Möglichkeit, alle Versionen einer Datei aus dem lokalen Speicher zu adressieren und zu wechseln.

Wenn Sie große, uniffable Dateien in Ihrem Repo wie Binärdateien haben, halten Sie eine vollständige Kopie dieser Datei in Ihrem Repo jedes Mal, wenn Sie eine Änderung an der Datei festlegen. Wenn viele Versionen dieser Dateien in Ihrem Repo vorhanden sind, erhöhen sie die Zeit zum Auschecken, Verzweigen, Abrufen und Klonen Ihres Codes.

Welche Art von Dateien sollten Sie in Git speichern?

Quellcode-nicht-Abhängigkeiten

Da Ihr Team mit Editoren und Tools arbeitet, um Dateien zu erstellen und zu aktualisieren, sollten Sie diese Dateien in Git einfügen, damit Ihr Team die Vorteile des Git-Workflows genießen kann. Setzen Sie keine anderen Dateientypen wie DLLs, Bibliotheksdateien und andere Abhängigkeiten fest, die nicht von Ihrem Team erstellt werden, aber Ihr Code hängt von Ihrem Repo ab. Liefern Sie diese Dateien über die Paketverwaltung an Ihre Systeme.

Die Paketverwaltung bündelt Ihre Abhängigkeiten und installiert die Dateien auf Ihrem System, wenn Sie das Paket bereitstellen. Pakete werden versioniert, um sicherzustellen, dass Code, der in einer Umgebung getestet wurde, in einer anderen Umgebung ausgeführt wird, solange dieselben installierten Pakete vorhanden sind.

Keine Commit-Ausgabe

Setzen Sie die Binärdateien, Protokolle, Ablaufverfolgungsausgabe oder Diagnosedaten aus Ihren Builds und Tests nicht fest. Dies sind Ausgabeen aus Ihrem Code, nicht der Quellcode selbst. Freigeben von Protokollen und Ablaufverfolgungsinformationen für Ihr Team über Arbeitselementverfolgungstools oder über die Teamdateifreigabe.

Speichern von kleinen, selten aktualisierten binären Quellen in Git

Binäre Quelldateien, die selten aktualisiert werden, verfügen über relativ wenige Versionen, und nehmen nicht sehr viel Speicherplatz auf, sofern ihre Dateigröße klein ist. Bilder für das Web, Symbole und andere kleinere Kunstressourcen können in diese Kategorie fallen. Es ist besser, diese Dateien in Git mit dem Rest Ihrer Quelle zu speichern, damit Ihr Team konsistenten Workflow verwenden kann.

Wichtig

Selbst kleine Binärdateien können Probleme verursachen, wenn sie häufig aktualisiert werden. Ein hundert Änderungen an einer 100 KB-Binärdatei verwendet so viel Speicher wie 10 Änderungen an einer 1 MB-Binärdatei, und aufgrund der Häufigkeit der Updates für die kleinere Binärdatei wird die Verzweigungsleistung häufiger als die große Binärdatei verlangsamt.

Übernehmen Sie keine großen, häufig aktualisierten binären Ressourcen

Git verwaltet eine Hauptversion einer Datei und speichert dann nur die Unterschiede von dieser Version in einem Prozess, der als Deltification bezeichnet wird. Deltification und Dateikomprimierung ermöglichen Git, Ihren gesamten Codeverlauf in Ihrem lokalen Repo zu speichern. Große Binärdateien ändern sich normalerweise vollständig zwischen Versionen und sind häufig bereits komprimiert, wodurch diese Dateien für Git schwierig zu verwalten sind, da der Unterschied zwischen Versionen sehr groß ist. Git muss den gesamten Inhalt jeder Version der Datei speichern und hat Schwierigkeiten, Speicherplatz durch Deltification und Komprimierung zu sparen. Das Speichern der vollständigen Dateiversionen dieser Dateien führt dazu, dass die Repo-Größe im Laufe der Zeit erhöht wird, die Verzweigungsleistung verringert, die Klonzeiten erhöht und die Speicheranforderungen erweitert werden.

Strategien zum Arbeiten mit großen binären Quelldateien

  • Fügen Sie keine komprimierten Archive von Daten fest. Es ist besser, die Dateien zu entkomprimieren und die diffablen Quellen festzulegen, damit Git die Komprimierung der Daten in Ihrem Repo verarbeitet.
  • Vermeiden Sie das Festlegen kompilierter Code und anderer binärer Abhängigkeiten. Setzen Sie die Quelle fest, und erstellen Sie die Abhängigkeiten, oder verwenden Sie eine Paketverwaltungslösung, um diese Dateien zu versionieren und an Ihr System bereitzustellen.
  • Speichern Sie Konfiguration und andere strukturierte Daten in diffablen Nur-Text-Formaten, z. B. JSON.

Verwenden von Git-LFS (Large File Storage)

Wenn Sie Quelldateien mit großen Unterschieden zwischen Versionen und häufigen Updates haben, können Sie Git LFS verwenden, um diese Dateitypen zu verwalten. Git LFS ist eine Erweiterung für Git, die Daten, die die großen Dateien in einem Commit zu Ihrem Repo beschreiben, und speichert den Binärdateiinhalt in separatem Remotespeicher. Wenn Sie zweigen in Ihrem Repo klonen und wechseln, lädt Git LFS die richtige Version aus diesem Remotespeicher herunter. Ihre lokalen Entwicklungstools arbeiten transparent mit den Dateien wie wenn sie direkt an Ihr Repo gebunden wurden.

Vorteile

Der Vorteil von Git LFS ist, dass Ihr Team den vertrauten End-to-End-Workflow verwenden kann, unabhängig davon, welche Dateien Ihr Team erstellt. LFS-Dateien können so groß sein, wie Sie sie benötigen. Darüber hinaus unterstützt Git LFS ab Version 2.0 die Dateisperre , um Ihr Team bei der Arbeit an großen, uniffablen Ressourcen wie Videos, Sounds und Spielkarten zu unterstützen.

Git LFS wird vollständig unterstützt und kostenlos in Azure DevOps Services. Um LFS mit Visual Studio zu verwenden, benötigen Sie mindestens Visual Studio 2015 Update 2. Führen Sie einfach die Anweisungen zum Installieren des Clients aus, richten Sie die LFS-Nachverfolgung für Dateien in Ihrem lokalen Repo ein, und drücken Sie dann Ihre Änderungen an Azure Repos.

Einschränkungen

Git LFS hat einige Nachteile, die Sie berücksichtigen sollten, bevor Sie folgendes übernehmen:

  1. Jeder von Ihrem Team verwendete Git-Client muss den Git LFS-Client installieren und seine Trackingkonfiguration verstehen.
  2. Wenn der Git LFS-Client nicht installiert und ordnungsgemäß konfiguriert ist, wird die binären Dateien, die über Git LFS ausgeführt werden, nicht angezeigt, wenn Sie Ihr Repo klonen. Git lädt die Daten herunter, die die große Datei beschreiben (was Git LFS zum Repo verpflichtet) und nicht die tatsächliche Binärdatei selbst. Wenn Sie große Binärdateien ohne den git LFS-Client installieren, wird die Binärdatei in Ihr Repo verschoben.
  3. Git kann die Änderungen aus zwei verschiedenen Versionen einer Binärdatei nicht zusammenführen, auch wenn beide Versionen über ein gemeinsames übergeordnetes Element verfügen. Wenn zwei Personen gleichzeitig an derselben Datei arbeiten, müssen sie zusammenarbeiten, um ihre Änderungen zu verbinden, um das Überschreiben der Arbeit des anderen zu vermeiden. Git LFS bietet Dateisperre , um Hilfe zu erhalten. Benutzer müssen immer noch die neueste Kopie eines binären Asset ziehen, bevor Sie mit der Arbeit beginnen.
  4. Azure Repos derzeit nicht die Verwendung von SSH in Repos mit Git LFS nachverfolgten Dateien unterstützt.
  5. Wenn ein Benutzer eine Binärdatei über die Webschnittstelle in ein Repo ziehen und abgibt, das für Git LFS konfiguriert ist, wird die Binärdatei an das Repo gebunden und nicht die Zeiger, die über den Git LFS-Client festgelegt würden.
  6. Der Grenzwert für die Dateigröße beträgt 50 GB.
  7. Ein Dateiuploadzeitlimit beträgt 1 Stunde.

Dateiformat

Die Datei, die in Ihr Repo für eine Git LFS-Nachverfolgte Datei geschrieben wurde, verfügt über einige Zeilen mit einem Schlüssel- und Wertpaar in jeder Zeile:

version https://git-lfs.github.com/spec/v1
oid a747cfbbef63fc0a3f5ffca332ae486ee7bf77c1d1b9b2de02e261ef97d085fe
size 4923023

Hinweis

Die GitHub-URL, die für den Versionswert enthalten ist, definiert nur den Dateityp LFS und ist kein Link zu Ihrer Binärdatei.

Bekannte Probleme

Wenn Sie eine Version von LFS unter 2.4.0 mit Azure DevOps Server oder TFS verwenden, ist ein zusätzlicher Setupschritt erforderlich, um NTLM anstelle von Kerberos zu authentifizieren. Dieser Schritt ist nicht mehr erforderlich als LFS 2.4.0, und es wird dringend empfohlen, upgraden.