Verwalten und Speichern großer Dateien in Git

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Git trägt dazu bei, den Fußabdruck Ihres Quellcodes klein zu halten, da die Unterschiede zwischen den Versionen leicht ausgewählt werden und Code einfach komprimiert wird. Große Dateien, die nicht gut komprimiert werden und die sich vollständig zwischen Versionen (z. B. Binärdateien) ändern, stellen Probleme dar, wenn sie in Ihrem Git-Repository gespeichert sind. Die schnelle Leistung von Git stammt von der Fähigkeit, alle Versionen einer Datei aus dem lokalen Speicher zu adressieren und zu wechseln.

Wenn In Ihrem Repository große, uniffrierbare Dateien vorhanden sind (z. B. Binärdateien), behalten Sie jedes Mal eine vollständige Kopie dieser Dateien in Ihrem Repository bei, wenn Sie eine Änderung daran übernehmen. 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 Arten von Dateien sollten Sie in Git speichern?

Commit des Quellcodes und nicht von Abhängigkeiten

Da Ihr Team mit Editoren und Tools zum Erstellen und Aktualisieren von Dateien arbeitet, sollten Sie diese Dateien in Git ablegen, damit Ihr Team die Vorteile des Git-Workflows genießen kann. Übernehmen Sie keine anderen Dateitypen in Ihr Repository, z. B. DLLs, Bibliotheksdateien und andere Abhängigkeiten, die Ihr Team nicht erstellt, aber Ihr Code hängt davon ab. Stellen Sie diese Dateien über die Paketverwaltung an Ihre Systeme 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 identisch ausgeführt wird, solange die Umgebungen dieselben installierten Pakete haben.

Keine Commit-Ausgaben ausführen

Übernehmen Sie keine Binärdateien, Protokolle, Ablaufverfolgungsausgabe oder Diagnosedaten aus Ihren Builds und Tests. Dies sind Ausgaben aus Ihrem Code, nicht der Quellcode selbst. Teilen Sie Protokolle und Ablaufverfolgungsinformationen mit Ihrem Team über Tools zur Nachverfolgung von Arbeitsaufgaben oder über die Teamdateifreigabe.

Speichern kleiner, selten aktualisierter binärer Quellen in Git

Binäre Quelldateien, die selten aktualisiert werden, haben relativ wenige Versionen zugesichert. Sie belegen nicht viel Speicherplatz, wenn ihre Dateigröße klein ist. Bilder für das Web, Symbole und andere kleinere Grafikobjekte können in diese Kategorie fallen. Es ist besser, diese Dateien in Git mit der restlichen Quelle zu speichern, damit Ihr Team einen konsistenten Workflow verwenden kann.

Ausführen eines Commits für große, häufig aktualisierte binärressourcen

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 das Speichern des gesamten Codeverlaufs in Ihrem lokalen Repository. 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 und hat Schwierigkeiten, Platz durch Deltification und Komprimierung 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 Verzweigungsleistung, erhöht die Klonzeiten und erweitert die Speicheranforderungen.

Strategien für das Arbeiten mit großen Binärquelldateien

• Übernehmen Sie keine komprimierten Archive von Daten. Es ist besser, die Dateien zu entkomprimieren und die diffablen Quellen zu übernehmen. Lassen Sie Git die Komprimierung der Daten in Ihrem Repository verarbeiten.
• Vermeiden Sie das Commit für kompilierten Code und andere binäre Abhängigkeiten. Übernehmen Sie die Quelle, 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 die Konfiguration und andere strukturierte Daten in diffablen Nur-Text-Formaten, z. B. JSON.

Was ist Git LFS?

Wenn Sie Über Quelldateien mit großen Unterschieden zwischen Versionen und häufigen Updates 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 Verzweigungen in Ihrem Repository klonen und wechseln, lädt Git LFS die richtige Version aus diesem Remotespeicher herunter. Ihre lokalen Entwicklungstools arbeiten transparent mit den Dateien zusammen, als ob sie direkt für Ihr Repository zugesichert wurden.

Vorteile

Ein Vorteil von Git LFS ist, dass Ihr Team den vertrauten End-to-End-Git-Workflow verwenden kann, unabhängig davon, welche Dateien Ihr Team erstellt. LFS verarbeitet große Dateien, um zu verhindern, dass sie sich negativ auf das gesamte Repository auswirken. Darüber hinaus unterstützt Git LFS ab Version 2.0 die Dateisperre , um Ihrem Team bei der Arbeit an großen, uniffrablen Ressourcen wie Videos, Sounds und Spielkarten zu helfen.

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

Einschränkungen

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

• Jeder von Ihrem Team verwendete Git-Client muss den Git LFS-Client installieren und seine Tracking-Konfiguration verstehen.
• Wenn der Git LFS-Client nicht installiert und ordnungsgemäß konfiguriert ist, werden die Binärdateien, die über Git LFS zugesichert werden, nicht angezeigt, wenn Sie Ihr Repository klonen. Git lädt die Daten herunter, die die große Datei beschreiben (was Git LFS für das Repository übernimmt) und nicht die Binärdatei. Durch das Commit großer Binärdateien ohne installierten Git LFS-Client wird die Binärdatei an Ihr Repository übertragen.
• 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 abzugleichen, um zu vermeiden, dass die Arbeit des anderen überschrieben wird. Git LFS stellt dateisperrende Hilfe bereit. Benutzer müssen immer noch die neueste Kopie einer binären Ressource abrufen, bevor Sie mit der Arbeit beginnen.
• Azure Repos unterstützt derzeit nicht die Verwendung von Secure Shell (SSH) in Repositorys mit Git LFS nachverfolgten Dateien.
• 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 an das Repository gebunden, nicht die Zeiger, die über den Git LFS-Client zugesichert werden.
• Obwohl es keine strikte Dateigrößeneinschränkung gibt, könnte der verfügbare speicherplatzfreie Speicherplatz und die aktuelle Workload die Leistung und Funktionalität des Servers einschränken.
• Das Zeitlimit für einen Dateiupload beträgt eine Stunde.

Dateiformat

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

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

Bekannte Probleme

Wenn Sie eine Version von LFS vor 2.4.0 mit Azure DevOps Server verwenden, ist ein zusätzlicher Setupschritt erforderlich, um sich über NTLM anstelle von Kerberos zu authentifizieren. Dieser Schritt ist ab LFS 2.4.0 nicht mehr erforderlich, und es wird dringend empfohlen, ein Upgrade durchzuführen.