Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Verwenden Sie Git für Quelldateien, Azure Artifacts für Abhängigkeiten und Git LFS für große Binärdateien, die sich häufig ändern. Wenn Ihr Repository bereits große Dateien enthält, hilft Ihnen dieser Artikel, zu entscheiden, was in Git beibehalten werden soll, was verschoben werden soll und wann Binärdateien aus dem Verlauf entfernt werden sollen.
Entscheiden, wo die einzelnen Dateien gespeichert werden sollen
Wenn Sie entscheiden, was sie mit Dateien tun sollen, die sich bereits in einem Repository befinden, beginnen Sie hier:
- Bewahren Sie Quelldateien, Skripts und Textdateien in Git auf.
- Verschieben sie Abhängigkeiten und wiederverwendbare Pakete in Azure Artifacts Paketverwaltung.
- Verwenden Sie Git LFS für große Binärdateien, die sich häufig ändern und nicht gut diffieren.
- Entfernen Sie große Binärdateien aus dem Repositoryverlauf, wenn sie bereits eingecheckt sind und nicht mehr dorthin gehören. Siehe Entfernen großer Dateien aus einem Repository.
Wenn Ihr Repository bereits groß ist, überprüfen Sie das Repository und pushlimits, bevor Sie einen Speicheransatz auswählen. Siehe Git-Grenzwerte für die Grenzwerte für Dateien, Push und Pfade, die sich auf große Repositorys auswirken.
Wählen Sie die richtige Speicheroption für Git, Paketverwaltung und Git LFS aus.
Verwenden Sie diese Tabelle, um die beste Anpassung zu wählen.
| Dateityp oder Szenario | Verwendung |
|---|---|
| Quellcode, Skripts und Textdateien | Git |
| Abhängigkeiten und wiederverwendbare Pakete | Azure Artifacts Paketverwaltung |
| Große Binärdateien, die sich häufig ändern | Git LFS |
| Azure DevOps Server Git LFS und Kerberos | Lesen Sie die Kerberos-Anleitungen in diesem Artikel und den verknüpften Artikel am Ende |
Git eignet sich am besten für textbasierte Quelldateien und andere Inhalte, die sich in kleinen, lesbaren Schritten ändern.
Große Binärdateien eignen sich nicht gut für regulären Git-Speicher, da:
- Git speichert Versionsunterschiede effizient für Quellcode, Skripts und Textdateien.
- Große Dateien, die sich vollständig zwischen Versionen ändern, komprimieren oder differenzieren sich nicht gut.
- Große Binärdateien verlängern die Zeiten für Klonen, Fetch, Branch und Checkout.
Wenn Sie ihrem Repository große, nicht veränderbare Dateien wie Binärdateien hinzufügen, behalten Sie jedes Mal eine vollständige Kopie dieser Dateien in Ihrem Repository bei, wenn Sie eine Änderung daran ausführen. 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 Dateien gehören in Git?
Verwenden Sie die einfachste Option, die dem Dateityp entspricht und wie oft sie geändert wird.
Quellcode in Git beibehalten, keine Abhängigkeiten
Verwenden Sie Git für Dateien, die Ihr Team direkt bearbeitet. Halten Sie Abhängigkeiten aus dem Repository heraus und stellen Sie sie über die Paketverwaltung bereit.
- Fügen Sie Quelldateien in Git ein.
- Speichern Sie DLLs, Bibliotheksdateien und andere Abhängigkeiten außerhalb des Repositorys.
- Verwenden Sie die Paketverwaltung, um Abhängigkeiten zu versionieren und bereitzustellen.
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.
Erstellen von Ausgabevorgängen nicht übernehmen
Verwenden Sie Git für den Quellcode, nicht für Buildausgaben oder Testartefakte.
- Übernehmen Sie keine Binärdateien, Protokolle, Ablaufverfolgungsausgabe oder Diagnosedaten.
- Freigeben von Protokollen und Ablaufverfolgungsinformationen über die Nachverfolgung von Arbeitsaufgaben oder die Freigabe von Teamdateien.
Speichern kleiner Binärdateien in Git
Verwenden Sie Git nur für kleine Binärdateien, wenn sie sich selten ändern.
- Zu den guten Beispielen gehören Webbilder, Symbole und andere kleine Kunstobjekte.
- Das Beibehalten dieser Dateien in Git behält einen konsistenten Workflow für das Team bei.
Von Bedeutung
Selbst kleine Binärdateien können Probleme verursachen, wenn sie häufig aktualisiert werden. Beispielsweise verwenden 100 Änderungen an einer 100-KB-Binärdatei so viel Speicher wie 10 Änderungen an einer 1-MB-Binärdatei. Aufgrund der Häufigkeit von Updates verlangsamt die kleinere Binärdatei die Verzweigungsleistung häufiger als die große Binärdatei.
Vermeiden Sie große, häufig aktualisierte binäre Ressourcen
Git kann große Binärdateien nicht effizient speichern, da sich diese Dateien häufig zwischen Versionen ändern und in der Regel bereits komprimiert sind.
- Git speichert den vollständigen Inhalt jeder Version.
- Die Repositorygröße wächst im Laufe der Zeit.
- Klon-, Branch-, Fetch- und Checkout-Vorgänge werden langsamer.
Da Git den vollständigen Inhalt jeder Version speichern muss, helfen Deltification und Komprimierung nicht viel. Wenn sich diese Dateien ansammeln, wird das Repository größer, das Erstellen von Branches wird langsamer und die Klonzeiten steigen.
Strategien für große Binärquelldateien
- Committen Sie keine komprimierten Archive. Dekomprimieren Sie stattdessen die Daten und committen Sie die diff-fähigen Quelldateien.
- Vermeiden Sie das Commit für kompilierten Code und andere binäre Abhängigkeiten. Erstellen Sie sie, oder stellen Sie sie über die Paketverwaltung zur Verfügung.
- Speichern Sie die Konfiguration und andere strukturierte Daten in diffablen Nur-Text-Formaten wie JSON.
Was ist Git Large File Storage (Git LFS)?
Verwenden Sie Git Large File Storage (LFS) für Quelldateien, die sich häufig ändern und zwischen Versionen erheblich unterscheiden.
Git LFS:
- Speichert Zeiger auf große Dateien in Ihrem Repository anstelle des vollständigen Dateiinhalts.
- Speichert den binären Inhalt im separaten Remotespeicher.
- Lädt die richtige Version herunter, wenn Sie ein Repository klonen oder den Branch wechseln.
- Behält Ihren normalen Git-Workflow für große Binärdateien bei, ohne den vollständigen Dateiinhalt durch jede Klon- und Verzweigungsänderung zu verschieben.
Vorteile von Git LFS
Git LFS behält den Git-Workflow bei, während große Dateiinhalte aus dem Haupt-Repository verschoben werden.
- Ihr Team kann weiterhin den gleichen End-to-End-Git-Workflow verwenden.
- Große Dateien bleiben aus dem Haupt-Repositoryverlauf heraus, wodurch das Repository verwaltbar bleibt.
- Die Dateisperrung unterstützt freigegebene Arbeit an großen, uniffrierbaren Ressourcen wie Videos, Sounds und Spielkarten.
Azure DevOps Services unterstützt Git LFS vollständig und bietet es kostenlos an. Um LFS zu verwenden, installieren Sie den Git LFS-Client, konfigurieren Sie die Nachverfolgung für die Dateien, die Sie in LFS speichern möchten, und übertragen Sie dann Ihre Änderungen an Azure Repos.
Informationen zu Azure DevOps Server und Kerberos-spezifischen Anleitungen finden Sie unter Kerberos und Git LFS.
Git LFS-Einschränkungen
Git LFS hat noch einige Einschränkungen, die Sie einplanen sollten:
- Jeder Git-Client muss den Git LFS-Client installieren und seine Tracking-Konfiguration verstehen.
- Wenn der Client nicht ordnungsgemäß installiert oder konfiguriert ist, laden Klonen Zeigerdaten anstelle der Binärdatei herunter.
- Git kann keine verschiedenen Versionen einer Binärdatei zusammenführen, sodass Teamkollegen immer noch Änderungen koordinieren müssen.
- Git LFS bietet Dateisperrung, aber Benutzer müssen die neueste Kopie trotzdem abrufen, bevor sie mit der Arbeit beginnen.
- Azure Repos unterstützt Secure Shell (SSH) nicht für Repositorys mit von Git LFS nachverfolgten Dateien.
- Beim Ziehen einer Binärdatei in die Weboberfläche wird die Binärdatei ins Repository committet, nicht der LFS-Zeiger.
- Große Uploads können durch den verfügbaren freien Speicherplatz, die aktuelle Arbeitsauslastung und das Einstündige Uploadlimit eingeschränkt werden.
Git LFS-Dateiformat
Die Datei, die Sie in Ihr Repository für eine Git LFS-Nachverfolgte Datei schreiben, 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
Hinweis
- Die für den Versionswert enthaltene GitHub-URL definiert nur den LFS-Zeigerdateityp. Es ist kein Link zu Ihrer Binärdatei.
- Aktualisieren Sie für Git LFS vor 2.10.0 mit Azure DevOps Server auf Git LFS 2.10.0 oder höher, um die Kerberos-Authentifizierung zu verwenden. Aktuelle Anleitungen finden Sie unter Kerberos und Git LFS und reconfigure Azure DevOps Server für die Verwendung von Kerberos anstelle von NTLM.
Planung für Azure DevOps Server und Kerberos
Wenn Sie Azure DevOps Server und die Windows-Authentifizierung verwenden, berücksichtigen Sie bei der Verwendung von Git LFS Kerberos. Git LFS 2.10.0 und höher unterstützt die Kerberos-Authentifizierung.
Wenn Sie ältere Azure DevOps Server Anleitungen aktualisieren müssen, beginnen Sie mit Kerberos und Git LFS und dem verknüpften Azure DevOps Server Authentifizierungsleitfaden.