Limiti Git

Servizi di Azure DevOps

Imponiamo limiti di risorse ai repository Git in Azure Repos per garantire affidabilità e disponibilità per tutti i clienti. Mantenendo ragionevoli le dimensioni dei dati e il numero di push, puoi aspettarti un'esperienza complessiva migliore con Git.

Git partecipa alla limitazione della frequenza insieme al resto di Azure DevOps Services. Inoltre, imponiamo limiti alla dimensione totale dei repository, ai push e alla lunghezza dei percorsi di file e directory.

Dimensioni del repository

I repository non devono essere più grandi di 250 GB. Per recuperare la dimensione del repository, esegui git count-objects -vH in un prompt dei comandi e cerca la voce chiamata "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

Ti consigliamo di mantenere il tuo repository al di sotto di 10 GB per ottenere prestazioni ottimali. Se il repository supera queste dimensioni, è consigliabile usare Git-LFS, Scalare o Azure Artifacts per gestire gli artefatti di sviluppo.

Azure Repos riduce continuamente le dimensioni complessive e aumenta l'efficienza dei repository Git consolidando i file simili in pacchetti. Per i repository di dimensioni prossime a 250 GB, il limite interno per i file di compressione può essere raggiunto prima del completamento del processo di ottimizzazione. Quando viene raggiunto questo limite, gli utenti che tentano di scrivere nel repository visualizzano il seguente messaggio di errore: "Il limite del file Git pack è stato raggiunto, le operazioni di scrittura sono temporaneamente non disponibili durante l'aggiornamento del repository". Le operazioni di scrittura vengono ripristinate immediatamente dopo il completamento del processo di ottimizzazione.

I file non devono essere più grandi di 100 MB. Questo limite consente di garantire prestazioni e affidabilità ottimali del repository Git. I file di grandi dimensioni possono rallentare notevolmente le operazioni del repository, come la clonazione, il recupero e il push delle modifiche. Se è necessario archiviare file di grandi dimensioni, è consigliabile utilizzare Git LFS (Large File Storage), progettato per gestire in modo efficiente file di grandi dimensioni archiviandoli all'esterno del repository principale e mantenendo solo i riferimenti ad essi all'interno del repository. Questo approccio consente di mantenere le prestazioni e la gestibilità del repository Git.

Dimensione della spinta

I push di grandi dimensioni utilizzano risorse significative, bloccando o rallentando altre parti del servizio. Questi push spesso non sono allineati con le attività di sviluppo software tipiche e potrebbero includere elementi come gli output di compilazione o le immagini delle macchine virtuali. Pertanto, i push sono limitati a 5 GB alla volta.

Esiste un'eccezione in cui i push di grandi dimensioni sono normali: la migrazione di un repository da un altro servizio in Azure Repos. Tali migrazioni arrivano come un singolo push e non intendiamo bloccare le importazioni, nemmeno per i repository di grandi dimensioni. Se il repository supera i 5 GB, è necessario utilizzare il Web per importare il repository anziché la riga di comando.

Dimensioni push per gli oggetti LFS

Git LFS non viene conteggiato ai fini del limite di 5 GB del repository. Il limite di 5 GB si applica solo ai file nel repository effettivo, non ai BLOB archiviati con LFS. Se si verificano push non riusciti a causa del limite di 5 GB, assicurarsi che il .gitattributes file includa le estensioni dei file che si intende monitorare con LFS. Assicurarsi che questo file sia salvato e gestito prima di eseguire lo staging dei file di grandi dimensioni da rilevare.

Lunghezza dei percorsi

Azure Repos applica un criterio push che limita la lunghezza dei percorsi in un repository Git rifiutando i push che introducono percorsi eccessivamente lunghi. A differenza del criterio di lunghezza massima del percorso, non è possibile disabilitarlo o sostituirlo, in quanto applica i valori massimi supportati dalla nostra piattaforma.

Vengono applicati i seguenti limiti:

• Lunghezza totale del percorso: 32.766 caratteri
• Lunghezza del componente del percorso (nome della cartella o del file): 4.096 caratteri

Questo criterio influisce solo sui percorsi appena introdotti in un push. Non si applica se si modifica un file esistente, ma si applica se si crea un nuovo file, se si rinomina o se se ne sposta uno esistente.

Se un commit di cui viene eseguito il push introduce percorsi che superano questi limiti, il push viene rifiutato con uno dei seguenti messaggi di errore:

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