Git-Grenzwerte

  • Artikel

Azure DevOps Services

Wir legen Ressourcenbeschränkungen für Git-Repositorys in Azure Repos fest, um Zuverlässigkeit und Verfügbarkeit für alle Kunden sicherzustellen. Durch eine angemessene Beschränkung der Datenmenge und der Anzahl von Pushvorgängen können Sie zudem insgesamt besseren Git-Komfort nutzen.

Wie alle Azure DevOps-Dienste nimmt Git an der Ratenbegrenzung teil. Darüber hinaus legen wir Beschränkungen für die Gesamtgröße von Repositorys, Pushes und die Länge von Datei- und Verzeichnispfaden fest.

Repositorygröße

Repositorys sollten nicht größer als 250 GB sein. Um die Größe Ihres Repositorys abzurufen, führen Sie git count-objects -vH in einer Eingabeaufforderung aus, und suchen Sie nach dem Eintrag mit dem Namen „size-pack“:

D:\my-repo>git count-objects -vH

count: 482
size: 551.67 KiB
in-pack: 100365
packs: 25
size-pack: 642.76 MiB   <-- size of repository
prune-packable: 83
garbage: 0
size-garbage: 0 bytes

Wir empfehlen, eine Repositorygröße von unter 10 GB zu verwenden, um eine optimale Leistung zu erzielen. Wenn Ihr Repository diese Größe überschreitet, sollten Sie Git-LFS, Scalar oder Azure Artifacts verwenden, um Ihre Entwicklungsartefakte zu verwalten.

Azure Repos reduziert kontinuierlich die Gesamtgröße und steigert die Effizienz von Git-Repositorys, indem ähnliche Dateien in Paketen konsolidiert werden. Bei Repositorys, die sich 250 GB nähern, kann der interne Grenzwert für Paketdateien erreicht werden, bevor der Optimierungsprozess abgeschlossen ist. Wenn dieser Grenzwert erreicht ist, wird Benutzern, die versuchen, in das Repository zu schreiben, die folgende Fehlermeldung angezeigt: „Der Grenzwert für Git-Pack-Dateien wurde erreicht, Schreibvorgänge sind vorübergehend nicht verfügbar, während das Repository aktualisiert wird.“ Schreibvorgänge werden sofort nach Abschluss des Optimierungsauftrags wiederhergestellt.

Dateien sollten nicht größer als 100 MB sein. Dieser Grenzwert trägt dazu bei, die optimale Leistung und Zuverlässigkeit des Git-Repositorys sicherzustellen. Große Dateien können Repositoryvorgänge wie Klonen, Abrufen und Pushen von Änderungen erheblich verlangsamen. Wenn Sie große Dateien speichern müssen, sollten Sie Git LFS (Large File Storage) verwenden, das für die effiziente Verarbeitung großer Dateien konzipiert ist, indem Sie sie außerhalb des Haupt-Repositorys speichern und nur Verweise darauf im Repository aufbewahren. Diese Vorgehensweise trägt dazu bei, die Leistung und Verwaltbarkeit Ihres Git-Repositorys aufrechtzuerhalten.

Pushgröße

Große Pushvorgänge verbrauchen erhebliche Ressourcen und blockieren oder verlangsamen andere Teile des Diensts. Diese Pushvorgänge passen häufig nicht zu typischen Softwareentwicklungsaktivitäten und enthalten möglicherweise Elemente wie Build-Ausgaben oder VM-Images. Daher sind Pushvorgänge auf jeweils 5 GB beschränkt.

Es gibt eine Ausnahme, bei der große Pushvorgänge normal sind: Das Migrieren eines Repositorys von einem anderen Dienst zu Azure Repos. Solche Migrationen werden als einzelner Pushvorgang durchgeführt, und wir beabsichtigen nicht, Importe zu blockieren, auch für große Repositorys. Wenn das Repository 5 GB überschreitet, müssen Sie das Web anstelle der Befehlszeile verwenden, um das Repository zu zu importieren.

Pushgröße für LFS-Objekte

Git LFS wird nicht auf das Repository-Limit von 5 GB angerechnet. Der Grenzwert von 5 GB gilt nur für Dateien im tatsächlichen Repository, nicht für Blobs, die mit LFS gespeichert sind. Wenn aufgrund des Grenzwerts von 5 GB Pushvorgänge fehlschlagen, stellen Sie sicher, dass Ihre .gitattributes-Datei die Erweiterungen der Dateien enthält, die Sie mit LFS nachverfolgen möchten. Stellen Sie sicher, dass diese Datei gespeichert wurde und Staging unterliegt, bevor Sie Staging für die großen Dateien durchführen, die nachverfolgt werden sollen.

Pfadlänge

Azure Repos erzwingt eine Push-Richtlinie, die die Länge von Pfaden in einem Git-Repository einschränkt, indem Pushvorgänge abgelehnt werden, die übermäßig lange Pfade einführen. Anders als die Richtlinie für die maximale Pfadlänge können Sie dies nicht deaktivieren oder übergehen, da es die maximale Zahl der von unserer Plattform unterstützten Werte erzwingt.

Die folgenden Einschränkungen werden erzwungen:

  • Gesamtlänge des Pfads: 32.766 Zeichen
  • Länge der Pfadkomponente (Ordner oder Dateiname): 4.096 Zeichen

Diese Richtlinie betrifft nur neu eingeführte Pfade in einem Pushvorgang. Sie gilt nicht, wenn Sie eine vorhandene Datei ändern, aber sie gilt, wenn Sie eine neue Datei erstellen, umbenennen oder eine vorhandene Datei verschieben.

Wenn Commits, die gepusht werden, Pfade einführen, die diese Grenzwerte überschreiten, wird der Pushvorgang mit einer der folgenden Fehlermeldungen abgelehnt:

  • VS403729: The push was rejected because commit '6fbe8dc700fdb33ef512e2b9e35436faf555de76' contains a path, which exceeds the maximum length of 32766 characters.
  • VS403729: The push was rejected because commit 'd23277abfe2d8dcbb88456da880de631994dabb4' contains a path component, which exceeds the maximum length of 4096 characters.