Delen via

Git-limieten

  • Artikel

Azure DevOps Services

We leggen resourcelimieten op voor Git-opslagplaatsen in Azure-opslagplaatsen om betrouwbaarheid en beschikbaarheid voor alle klanten te garanderen. Door gegevensgrootten en het aantal pushs redelijk te houden, kunt u 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 git count-objects -vH u de opdrachtprompt uit en zoekt u de vermelding '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 optimale prestaties. Als uw opslagplaats deze grootte overschrijdt, kunt u overwegen Git-LFS, Scalar of Azure Artifacts te gebruiken om uw ontwikkelartefacten te beheren.

Azure-opslagplaatsen vermindert voortdurend de totale grootte en verhoogt de efficiëntie van Git-opslagplaatsen door vergelijkbare bestanden in packs samen te brengen. Voor opslagplaatsen die bijna 250 GB naderen, kan de interne limiet voor packbestanden worden bereikt voordat het optimalisatieproces is voltooid. Wanneer deze limiet is bereikt, zien gebruikers die naar de opslagplaats willen schrijven het volgende foutbericht: 'De limiet voor het Git Pack-bestand is bereikt, schrijfbewerkingen zijn tijdelijk niet beschikbaar terwijl de opslagplaats wordt bijgewerkt'. Schrijfbewerkingen worden onmiddellijk hersteld nadat de optimalisatietaak is voltooid.

Bestanden mogen niet groter zijn dan 100 MB. Deze limiet zorgt voor optimale prestaties en betrouwbaarheid van de Git-opslagplaats. Grote bestanden kunnen de bewerkingen van de opslagplaats aanzienlijk vertragen, zoals klonen, ophalen en pushen van wijzigingen. Als u grote bestanden wilt opslaan, kunt u overwegen Om Git LFS (Large File Storage) te gebruiken, die is ontworpen om grote bestanden efficiënt te verwerken door ze buiten de hoofdopslagplaats op te slaan en alleen verwijzingen naar deze bestanden in de opslagplaats te bewaren. Deze aanpak helpt de prestaties en beheerbaarheid van uw Git-opslagplaats te behouden.

Pushgrootte

Grote pushes verbruiken aanzienlijke resources, blokkeren of vertragen andere onderdelen van de service. Deze pushes zijn vaak niet afgestemd op typische softwareontwikkelingsactiviteiten en bevatten mogelijk items zoals build-uitvoer of VM-installatiekopieën. Pushes zijn daarom beperkt tot 5 GB tegelijk.

Er is één uitzondering waarbij grote pushes normaal zijn: een opslagplaats migreren van een andere service naar Azure-opslagplaatsen. Dergelijke migraties komen binnen als één push en we zijn niet van plan om importbewerkingen te blokkeren, zelfs voor 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.

Pushgrootte voor LFS-objecten

Git LFS telt niet mee voor de limiet van 5 GB-opslagplaatsen. De limiet van 5 GB geldt alleen voor bestanden in de werkelijke opslagplaats, niet voor blobs die zijn opgeslagen met LFS. Als u mislukte pushes ondervindt vanwege de limiet van 5 GB, moet u ervoor zorgen dat uw .gitattributes bestand de extensies bevat van de bestanden die u wilt bijhouden met LFS. Zorg ervoor dat dit bestand is opgeslagen en gefaseerd voordat u de grote bestanden klaarhoudt die moeten worden bijgehouden.

Padlengte

Azure-opslagplaatsen dwingt een pushbeleid af waarmee de lengte van paden in een Git-opslagplaats wordt beperkt door pushes te weigeren die overmatig lange paden introduceren. In tegenstelling tot het beleid voor maximale padlengte kunt u dit niet uitschakelen of negeren, omdat hiermee de maximumwaarden worden afgedwongen die door ons platform worden ondersteund.

De volgende limieten worden afgedwongen:

  • Totale padlengte: 32.766 tekens
  • Lengte padonderdeel (map of bestandsnaam): 4.096 tekens

Dit beleid is alleen van invloed op nieuw geïntroduceerde paden in een push. Het is niet van toepassing als u een bestaand bestand wijzigt, maar dit wel van toepassing is als u een nieuw bestand maakt, een nieuwe naam geeft of een bestaand bestand verplaatst.

Als doorvoeringen die worden gepusht paden introduceren die deze 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.