Git-Grenzwerte

Azure DevOps Services

Wir legen Ressourcengrenzwerte für Git-Repositorys in Azure Repos fest, um die Zuverlässigkeit und Verfügbarkeit für alle Kunden sicherzustellen. Indem Sie die Datengröße und die Anzahl der Pushvorgänge angemessen halten, können Sie eine bessere Gesamterfahrung mit Git erwarten.

Git nimmt zusammen mit dem Rest von Azure DevOps Services 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.

Größe des Repositorys

Repositorys sollten nicht größer als 250 GB sein. Um die Größe Ihres Repositorys abzurufen, führen Sie es in einer Eingabeaufforderung aus git count-objects -vH und suchen Sie nach dem Eintrag "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, Ihr Repository unter 10 GB zu halten, um eine optimale Leistung zu erzielen. Wenn Ihr Repository diese Größe überschreitet, sollten Sie die Verwendung von Git-LFS, Scalar oder Azure Artifacts in Betracht ziehen, 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 Repositories mit einer Größe von fast 250 GB kann das interne Limit für Pack-Dateien 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: "Das Limit 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, eine optimale Leistung und Zuverlässigkeit des Git-Repositorys sicherzustellen. Große Dateien können Repository-Vorgänge wie Klonen, Abrufen und Übertragen von Änderungen erheblich verlangsamen. Wenn Sie große Dateien speichern müssen, sollten Sie die Verwendung von Git LFS (Large File Storage) in Betracht ziehen, das darauf ausgelegt ist, große Dateien effizient zu verarbeiten, indem sie außerhalb des Hauptrepositorys gespeichert und nur Verweise auf sie innerhalb des Repositorys aufbewahrt werden. Dieser Ansatz trägt dazu bei, die Leistung und Verwaltbarkeit Ihres Git-Repositorys zu erhalten.

Push-Größe

Große Pushvorgänge verbrauchen erhebliche Ressourcen und blockieren oder verlangsamen andere Teile des Dienstes. Diese Pushvorgänge stimmen oft nicht mit typischen Softwareentwicklungsaktivitäten überein und können Elemente wie Buildausgaben oder VM-Images umfassen. 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 erfolgen in einem einzigen Schub, und wir beabsichtigen nicht, Importe zu blockieren, selbst nicht für große Repositories. Wenn das Repository 5 GB überschreitet, müssen Sie das Web anstelle der Befehlszeile verwenden, um das Repository zu importieren .

Push-Größ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 eigentlichen Repository, nicht für Blobs, die mit LFS gespeichert sind. Wenn aufgrund des Limits von 5 GB fehlgeschlagene Pushvorgänge auftreten, 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 und bereitgestellt wird, bevor Sie die großen Dateien bereitstellen, die nachverfolgt werden sollen.

Pfadlänge

Azure Repos erzwingt eine Pushrichtlinie, die die Länge von Pfaden in einem Git-Repository begrenzt, indem Pushs abgelehnt werden, die übermäßig lange Pfade einführen. Im Gegensatz zur Richtlinie "Maximale Pfadlänge" können Sie sie nicht deaktivieren oder außer Kraft setzen, da sie die von unserer Plattform unterstützten Maximalwerte erzwingt.

Die folgenden Grenzwerte werden erzwungen:

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

Diese Richtlinie wirkt sich nur auf neu eingeführte Pfade in einem Push aus. 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 Push 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.