Share via

Git-limieten

  • Artikel

Azure DevOps Services

We leggen een aantal resourcelimieten op voor Git-opslagplaatsen in Azure-opslagplaatsen. Ons doel is de betrouwbaarheid en beschikbaarheid voor alle klanten te garanderen. Door de hoeveelheid gegevens en het aantal pushes redelijk te houden, kunt u ook een betere algehele ervaring met Git verwachten.

Git neemt deel aan snelheidsbeperking , samen met de rest van Azure DevOps Services. Daarnaast leggen we limieten op voor de totale grootte van opslagplaatsen, pushes en de lengte van bestands- en mappaden.

Grootte van opslagplaats

Opslagplaatsen mogen niet groter zijn dan 250 GB. Als u de grootte van uw opslagplaats wilt ophalen, voert u 'git count-objects -vH' uit in een opdrachtprompt en zoekt u naar de vermelding met de naam '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

We raden u aan uw opslagplaats onder de 10 GB te houden voor een optimale werking. Als uw opslagplaats deze grootte overschrijdt, kunt u overwegen om Git-LFS, Scalar of Azure Artifacts te gebruiken om uw ontwikkelartefacten te herstructureren.

Azure-opslagplaatsen verminderen voortdurend de totale grootte en verhogen de efficiëntie van Git-opslagplaatsen door vergelijkbare bestanden in pakketten samen te brengen. Voor opslagplaatsen die bijna 250 GB bereiken, kan de interne limiet voor pakketbestanden worden bereikt voordat het optimalisatieproces is voltooid. Elke gebruiker die naar de opslagplaats wil schrijven, krijgt het volgende foutbericht te zien: 'De bestandslimiet van het Git-pakket is bereikt, schrijfbewerkingen zijn tijdelijk niet beschikbaar terwijl de opslagplaats wordt bijgewerkt'. Schrijfbewerkingen worden onmiddellijk hersteld nadat de taak is voltooid.

Push-grootte

Grote pushs gebruiken veel resources, waardoor andere onderdelen van de service worden geblokkeerd of vertraagd. Dergelijke pushs wijzen vaak niet toe aan normale softwareontwikkelingsactiviteiten. Iemand heeft bijvoorbeeld onbedoeld build-uitvoer of een VM-installatiekopieën gecontroleerd. Om deze redenen en meer zijn pushes beperkt tot 5 GB tegelijk.

Er is één uitzondering waarbij grote pushes normaal zijn. Wanneer u een opslagplaats van een andere service migreert naar Azure-opslagplaatsen, wordt deze als één push geleverd. Het is niet de bedoeling om importbewerkingen te blokkeren, zelfs niet van zeer grote opslagplaatsen. Als de opslagplaats groter is dan 5 GB, moet u het web gebruiken om de opslagplaats te importeren in plaats van de opdrachtregel.

Push-grootte voor LFS-objecten

Git LFS telt niet mee voor de limiet van 5 GB voor opslagplaatsen. De limiet van 5 GB geldt alleen voor bestanden in de werkelijke opslagplaats, niet voor blobs die zijn opgeslagen als onderdeel van LFS. Als u mislukte pushes krijgt op de limiet van 5 GB, controleert u of uw .gitattributes bestand de extensies bevat van de bestanden die u wilt bijhouden met LFS en of dit bestand is opgeslagen en gefaseerd voordat u de grote bestanden hebt gefaseerd die moeten worden gevolgd.

Padlengte

Azure-opslagplaatsen heeft een pushbeleid dat de lengte van paden in een Git-opslagplaats beperkt door pushes die te lange paden introduceren, te weigeren. In tegenstelling tot beleid voor maximale padlengte is er geen manier om dit beleid uit te schakelen of te overschrijven met een andere limiet, omdat het de maximaal mogelijke waarden afdwingt die door ons platform worden ondersteund.

Er worden twee limieten afgedwongen:

  • Totale padlengte: 32.766 tekens
  • Lengte van padonderdeel (dat wil gezegd, map- of bestandsnaam): 4096 tekens

Dit is alleen van invloed op nieuw geïntroduceerde paden in een push. Als u een bestaand bestand wijzigt, is dit niet van toepassing. Maar als u een nieuw bestand maakt of de naam van een bestaand bestand wijzigt of verplaatst, is dit wel van toepassing.

Als sommige van de doorvoeringen die worden gepusht paden introduceren die de limieten overschrijden, wordt de push geweigerd met een van de volgende foutberichten:

  • 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.