Verwalten und Speichern großer Dateien in Git

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Mit Git bleibt der Platzbedarf Ihres Quellcodes klein, da die Unterschiede zwischen den Versionen leicht feststellbar sind und der Code komprimiert wird. Große Dateien, die nicht gut komprimiert werden und sich zwischen Versionen vollständig ändern (z. B. Binärdateien), sind problematisch, wenn sie in Ihren Git-Repositorys gespeichert werden. Die hohe Leistung von Git beruht auf der Fähigkeit, alle Versionen einer Datei im lokalen Speicher zu adressieren und zu wechseln.

Bei großen, nicht mit einem Difftool verarbeitbaren Dateien in Ihrem Repository (wie Binärdateien) wird jedes Mal eine vollständige Kopie dieser Dateien in Ihrem Repository beibehalten, wenn Sie eine Änderung an ihnen committen. Wenn viele Versionen dieser Dateien in Ihrem Repository vorhanden sind, wird die Zeit zum Auschecken, Branchen, Abrufen und Klonen des Codes erheblich erhöht.

Welche Arten von Dateien sollten Sie in Git speichern?

Commit-Quellcode, keine Abhängigkeiten

Da Ihr Team Editoren und Tools verwendet, um Dateien zu erstellen und zu aktualisieren, sollten Sie diese Dateien in Git speichern, damit Ihr Team die Vorteile des Git-Workflows nutzen kann. Committen Sie im Repository keine anderen Dateitypen in Ihr Repository: z. B. DLLs, Bibliotheksdateien und andere Abhängigkeiten, die Ihr Team nicht erstellt, aber von denen Ihr Code abhängt. Stellen Sie diese Dateien über die Paketverwaltung auf Ihren Systemen bereit.

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 genauso ausgeführt wird, solange in den Umgebungen dieselben installierten Pakete vorhanden sind.

Committen Sie keine Ausgaben

Committen Sie keine Binärdateien, Protokolle, Ablaufverfolgungsausgaben oder Diagnosedaten Ihrer Builds und Tests. Dabei handelt es sich um Ausgaben Ihres Code, nicht um den Quellcode selbst. Teilen Sie Protokolle und Ablaufverfolgungsinformationen für Ihr Team über Tools zum Nachverfolgen von Arbeitselementen oder über die Teamdateifreigabe.

Speichern kleiner, selten aktualisierter Binärquellen in Git

Bei binären Quelldateien, die selten aktualisiert werden, sind relativ wenige Versionen festgeschrieben. Sie belegen nicht viel Speicherplatz, wenn ihre Dateigröße klein ist. Bilder für das Web, Symbole und andere kleinere Kunstobjekte können in diese Kategorie fallen. Es ist besser, diese Dateien in Git mit dem Rest Ihres Quellcodes zu speichern, damit Ihr Team einen konsistenten Workflow verwenden kann.

Wichtig

Selbst kleine Binärdateien können Probleme verursachen, wenn sie häufig aktualisiert werden. Beispielsweise verbrauchen 100 Änderungen an einer 100-KB-Binärdatei genauso viel Speicherplatz wie 10 Änderungen an einer 1-MB-Binärdatei. Aufgrund der Häufigkeit von Updates verlangsamt die kleinere Binärdatei die Branch-Leistung häufiger als die große Binärdatei.

Committen Sie keine großen, häufig aktualisierten Binärressourcen

Git verwaltet eine Hauptversion einer Datei und speichert dann nur die Unterschiede zu dieser Version in einem Prozess, der als Deltification bezeichnet wird. Deltification und Dateikomprimierung ermöglichen es Git, den gesamten Codeverlauf in Ihrem lokalen Repository zu speichern. Große Binärdateien ändern sich in der Regel vollständig zwischen Versionen und werden häufig bereits komprimiert. Diese Dateien sind für Git schwierig zu verwalten, da die Unterschiede zwischen den Versionen groß sind.

Git muss den gesamten Inhalt jeder Version der Datei speichern, sodass es schwierig ist, durch Deltification und Komprimierung Speicherplatz zu sparen. Durch das Speichern der Vollversionen dieser Dateien wird die Größe des Repositorys im Laufe der Zeit erhöht. Die erhöhte Größe des Repositorys reduziert die Branch-Leistung, erhöht die Klonzeiten und erweitert die Speicheranforderungen.

Strategien für die Arbeit mit großen Binärquelldateien

  • Committen Sie keine komprimierten Datenarchive. Es ist besser, die Dateien zu dekomprimieren und die variablen Quellen zu übertragen. Lassen Sie Git die Komprimierung der Daten in Ihrem Repository verarbeiten.
  • Vermeiden Sie das Committen von kompiliertem Code und anderen binären Abhängigkeiten. Committen Sie den Quellcode, und erstellen Sie die Abhängigkeiten, oder verwenden Sie eine Paketverwaltungslösung, um diese Dateien zu versionieren und für Ihr System bereitzustellen.
  • Speichern Sie Konfigurationsdaten und andere strukturierte Daten in Nur-Text-Formaten, die mit einem Difftool verarbeitet werden können, z. B. JSON.

Was ist Git LFS?

Wenn Sie über Quelldateien mit großen Unterschieden zwischen den Versionen und häufigen Aktualisierungen verfügen, können Sie Git Large File Storage (LFS) verwenden, um diese Dateitypen zu verwalten. Git LFS ist eine Erweiterung für Git, die Daten bereitstellt, die die großen Dateien in einem Commit für Ihr Repository beschreiben. Der Inhalt der Binärdatei wird in einem separaten Remotespeicher gespeichert.

Wenn Sie in Ihrem Repository klonen und den Branch wechseln, lädt Git LFS die richtige Version von diesem Remotespeicher herunter. Ihre lokalen Entwicklungstools werden mit den Dateien transparent arbeiten, als ob sie direkt in Ihr Repository committet worden wären.

Vorteile

Ein Vorteil von Git LFS besteht darin, dass Ihr Team den vertrauten End-to-End-Git-Workflow verwenden kann, unabhängig davon, welche Dateien Ihr Team erstellt. LFS behandelt große Dateien, um zu verhindern, dass sie sich negativ auf das gesamte Repository auswirken. Außerdem unterstützt Git LFS ab Version 2.0 das Sperren von Dateien, damit Ihr Team an großen, unveränderlichen Ressourcen wie Videos, Sounds und Maps in Spielen arbeiten kann.

Git LFS wird von Azure DevOps Services vollständig unterstützt und ist kostenlos. Damit Sie LFS mit Visual Studio verwenden können, benötigen Sie Visual Studio 2015 Update 2 oder höher. Folgen Sie einfach den Anweisungen, um den Client zu installieren, die LFS-Nachverfolgung für Dateien in Ihrem lokalen Repository festzulegen und dann Ihre Änderungen zu Azure Repos zu pushen.

Begrenzungen

Git LFS hat einige Nachteile, die Sie bedenken sollten, bevor Sie es einführen:

  • Jeder Git-Client, der von Ihrem Team verwendet wird, muss den Git LFS-Client installieren und seine Nachverfolgungskonfiguration verstehen.
  • Wenn der Git LFS-Client nicht ordnungsgemäß installiert und konfiguriert ist, sehen Sie die über Git LFS committeten Binärdateien nicht, wenn Sie Ihr Repository klonen. Git lädt die Daten herunter, die die große Datei beschreiben (das ist das, was Git LFS zum Repository committet), und nicht die Binärdatei selbst. Wenn Sie große Binärdateien committen, ohne den Git LFS-Client installiert zu haben, wird die Binärdatei in Ihr Repository gepusht.
  • Git kann die Änderungen von zwei verschiedenen Versionen einer Binärdatei nicht zusammenführen, selbst wenn beide Versionen einen gemeinsamen übergeordneten Ursprung haben. Wenn zwei Personen gleichzeitig an der gleichen Datei arbeiten, müssen sie ihre Änderungen gemeinsam abstimmen, um zu vermeiden, dass die Arbeit des anderen überschrieben wird. Git LFS bietet eine Dateisperre zur Unterstützung. Benutzer müssen dennoch darauf achten, dass sie immer die aktuellste Kopie einer binären Ressource pullen, bevor sie mit der Arbeit beginnen.
  • Azure Repos unterstützt derzeit nicht die Verwendung von Secure Shell (SSH) in Repositorys mit Dateien, die mit Git LFS nachverfolgt werden.
  • Wenn ein Benutzer eine Binärdatei über die Weboberfläche in ein Repository zieht, das für Git LFS konfiguriert ist, wird die Binärdatei in das Repository committet und nicht die Zeiger, die über den Git LFS-Client committet werden würden.
  • Obwohl es keine strikte Beschränkung der Dateigröße gibt, können der verfügbare freie Speicherplatz des Servers und die aktuelle Arbeitslast die Leistung und Funktionalität einschränken.
  • Das Zeitlimit für einen Datei-Upload beträgt eine Stunde.

Dateiformat

Die Datei, die Sie in Ihr Repository für eine mit Git LFS nachverfolgte Datei schreiben, besteht aus einigen Zeilen mit einem Schlüssel-Wert-Paar in jeder Zeile:

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

Hinweis

Die für den Versionswert enthaltene GitHub-URL definiert nur den LFS-Zeigerdateityp. Es ist kein Link zu Ihrer Binärdatei.

Bekannte Probleme

Wenn Sie eine Version von LFS unter 2.4.0 mit Azure DevOps Server verwenden, ist ein zusätzlicher Einrichtungsschritt erforderlich, um sich mithilfe von NTLM anstelle von Kerberos zu authentifizieren. Dieser Schritt ist ab LFS 2.4.0 nicht mehr erforderlich, und wir empfehlen Ihnen dringend ein Upgrade.