Verwalten und Speichern großer Dateien in Git

  • Artikel
  • 6 Minuten Lesedauer

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 – TFS 2015

Git ist ideal, um den Speicherbedarf Ihres Quellcodes gering zu halten, da die Unterschiede zwischen den Versionen leicht auswählbar sind und Code leicht komprimiert werden kann. Große Dateien, die nicht gut komprimiert werden und sich zwischen Versionen (z. B. Binärdateien) vollständig ändern, stellen Probleme bei der Speicherung in Ihren Git-Repositorys vor. Die schnelle Leistung von Git entsteht durch die Möglichkeit, alle Versionen einer Datei aus dem lokalen Speicher zu adressen und zu diesen zu wechseln.

Wenn Ihr Repository große, unflädbare Dateien enthält, z. B. Binärdateien, behalten Sie jedes Mal eine vollständige Kopie dieser Datei in Ihrem Repository bei, wenn Sie eine Änderung an der Datei commiten. Wenn viele Versionen dieser Dateien in Ihrem Repository vorhanden sind, erhöhen sie die Zeit zum Auschecken, Verzweigen, Abrufen und Klonen Ihres Codes erheblich.

Welche Art von Dateien sollten Sie in Git speichern?

Quellcode, keine Abhängigkeiten

Da Ihr Team mit Editoren und Tools zum Erstellen und Aktualisieren von Dateien arbeitet, sollten Sie diese Dateien in Git speichern, damit Ihr Team von den Vorteilen des Git-Workflows profitieren kann. Führen Sie keinen Commit für andere Dateitypen aus, z. B. DLLs, Bibliotheksdateien und andere Abhängigkeiten, die nicht von Ihrem Team erstellt werden, aber Ihr Code hängt von Ihrem Repository ab. Stellen Sie diese Dateien über die Paketverwaltung für Ihre Systeme zur Verfügung.

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 in einer Umgebung getesteter Code in einer anderen Umgebung gleich ausgeführt wird, solange sie über die gleichen installierten Pakete verfügen.

Keine Commits für Ausgaben

Commits für die Binärdateien, Protokolle, Ablaufverfolgungsausgabe- oder Diagnosedaten aus Ihren Builds und Tests sind nicht möglich. Dies sind Ausgaben ihres Codes, nicht der Quellcode selbst. Geben Sie Protokolle und Ablaufverfolgungsinformationen mitHilfe von Tools zur Nachverfolgung von Arbeitselementen oder über die Gemeinsame Nutzung von Teamdateien für Ihr Team weiter.

Store, selten aktualisierte binäre Quellen in Git

Binäre Quelldateien, die selten aktualisiert werden, verfügen über relativ wenige Versionen, für die ein Committed erfolgt, und nehmen nicht sehr viel Speicherplatz inNe, vorausgesetzt, ihre Dateigröße ist klein. Bilder für das Web, Symbole und andere kleinere Artefakte können in diese Kategorie fallen. Es ist besser, diese Dateien in Git mit dem Rest Ihrer Quelle 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. 100 Änderungen an einer Binärdatei mit 100 KB nutzen so viel Speicher wie 10 Änderungen an einer 1-MB-Binärdatei, und aufgrund der Häufigkeit von Updates für die kleinere Binärdatei wird die Verzweigungsleistung häufiger als bei der großen Binärdatei verlangsamt.

Commits für große, häufig aktualisierte binäre Ressourcen nicht

Git verwaltet eine Hauptversion einer Datei und speichern dann nur die Unterschiede zu dieser Version in einem Prozess, der als Entschrung bezeichnet wird. Durch Entfältigung und Dateikomprimierung kann Git Den gesamten Codeverlauf in Ihrem lokalen Repository speichern. Große Binärdateien ändern sich in der Regel vollständig zwischen versionen und sind häufig bereits komprimiert, was die Verwaltung dieser Dateien für Git erschwert, da der Unterschied zwischen den Versionen sehr groß ist. Git muss den gesamten Inhalt jeder Version der Datei speichern und hat Schwierigkeiten, Speicherplatz durch Entfältigung und Komprimierung zu sparen. Das Speichern der vollständigen Dateiversionen dieser Dateien führt dazu, dass sich die Repositorygröße im Laufe der Zeit erhöht, die Verzweigungsleistung reduziert, die Klonzeiten erhöht und die Speicheranforderungen erweitert werden.

Strategien für die Arbeit mit großen binären Quelldateien

  • Commits für komprimierte Datenarchive nicht. Es ist besser, die Dateien zu entkomprimieren und die differenzierbaren Quellen zu commiten, damit Git die Komprimierung der Daten in Ihrem Repository verarbeiten kann.
  • Vermeiden Sie das Committen von kompiliertem Code und anderen binären Abhängigkeiten. Führen Sie einen Commit für die Quelle aus, und erstellen Sie die Abhängigkeiten, oder verwenden Sie eine Paketverwaltungslösung, um eine Version zu erstellen und diese Dateien für Ihr System zur Bereitstellung zu verwenden.
  • Store Konfiguration und andere strukturierte Daten in diffablen Nur-Text-Formaten, z. B. JSON.

Verwenden von Git-LFS (Large File Storage)

Wenn Sie über Quelldateien mit großen Unterschieden zwischen Versionen und häufigen Updates verfügen, können Sie diese Dateitypen mitHilfe von Git LFS verwalten. Git LFS ist eine Erweiterung für Git, die Daten, die die großen Dateien in einem Commit in Ihrem Repository beschreiben, committ und den Inhalt der Binärdatei in separatem Remotespeicher speichert. Wenn Sie Branches in Ihrem Repository klonen und wechseln, lädt Git LFS die richtige Version aus diesem Remotespeicher herunter. Ihre lokalen Entwicklungstools funktionieren transparent mit den Dateien, als ob sie direkt in Ihr Repository gebunden würden.

Vorteile

Der Vorteil von Git LFS ist, dass Ihr Team den vertrauten End-to-End-Git-Workflow unabhängig davon verwenden kann, 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 Dateisperren, um Ihr Team bei der Arbeit an großen, unerkannten Ressourcen wie Videos, Sounds und Spielkarten zu unterstützen.

Git LFS wird vollständig unterstützt und ist in der Azure DevOps Services. Um LFS mit Visual Studio verwenden zu können, benötigen Sie mindestens Visual Studio 2015 Update 2. Befolgen Sie einfach die Anweisungen zum Installieren des Clients, einrichten Sie die LFS-Nachverfolgung für Dateien in Ihrem lokalen Repository, und pushen Sie ihre Änderungen dann Azure Repos.

Einschränkungen

Git LFS hat einige Nachteile, die Sie vor der Einführung berücksichtigen sollten:

  1. Jeder Git-Client, der von Ihrem Team verwendet wird, muss den Git LFS-Client installieren und seine Nachverfolgungskonfiguration verstehen.
  2. Wenn der Git LFS-Client nicht ordnungsgemäß installiert und konfiguriert ist, werden die binären Dateien, für die ein Commit über Git LFS ausgeführt wurde, nicht angezeigt, wenn Sie Ihr Repository klonen. Git wird die Daten herunterladen, die die große Datei beschreiben (was Git LFS für das Repository committ) und nicht die eigentliche Binärdatei selbst. Wenn Sie große Binärdateien committen, ohne dass der Git LFS-Client installiert ist, pusht die Binärdatei in Ihr Repository.
  3. Git kann die Änderungen aus zwei verschiedenen Versionen einer Binärdatei auch dann nicht zusammenführen, 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 abstimmen zu können, um zu vermeiden, dass die Arbeit des anderen überschreiben wird. Git LFS bietet Dateisperren als Hilfe. Benutzer müssen weiterhin darauf achten, immer die neueste Kopie eines binären Assets zu pullen, bevor sie mit der Arbeit beginnen.
  4. Azure Repos unterstützt derzeit nicht die Verwendung von SSH in Repositorys mit nachverfolgten Git LFS-Dateien.
  5. Wenn ein Benutzer eine Binärdatei per Drag & Drop über die Webschnittstelle in ein Repository zieht, das für Git LFS konfiguriert ist, wird die Binärdatei in das Repository und nicht die Zeiger, für die ein Commit über den Git LFS-Client ausgeführt wird, ausgeführt.
  6. Der Grenzwert für die Dateigröße beträgt 50 GB.
  7. Ein Dateiuploadzeitlimit beträgt 1 Stunde.

Dateiformat

Die Datei, die für eine nachverfolgte Git LFS-Datei in Ihr Repository geschrieben wird, enthält in jeder Zeile einige Zeilen mit einem Schlüssel-Wert-Paar:

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 LFS-Zeigerdateityp 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 Einrichtungsschritt erforderlich, um sich mit NTLM anstelle von Kerberos zu authentifizieren. Dieser Schritt ist ab LFS 2.4.0 nicht mehr erforderlich, und es wird dringend empfohlen, ein Upgrade zu durchführen.