Compartir a través de

Límites de Git

  • Artículo

Azure DevOps Services

Imponemos límites de recursos de repositorios en Git en Azure Repos para garantizar la confiabilidad y disponibilidad de todos los clientes. Al mantener el tamaño de datos y el número de inserciones razonable, puede esperar una mejor experiencia general con Git.

Git participa en la limitación de frecuencia junto con el resto de Azure DevOps Services. Además, imponemos límites en el tamaño total de los repositorios, las inserciones y la longitud de las rutas de acceso de archivos y directorios.

Tamaño del repositorio

Los repositorios no deben tener más de 250 GB. Para recuperar el tamaño del repositorio, ejecute git count-objects -vH en un símbolo del sistema y busque la entrada denominada "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

Se recomienda mantener el tamaño del repositorio por debajo de 10 GB para obtener un rendimiento óptimo. Si el repositorio supera este tamaño, considere la posibilidad de usar Git-LFS, Scalar o Azure Artifacts para administrar los artefactos de desarrollo.

Azure Repos reduce continuamente el tamaño total y aumenta la eficacia de los repositorios de Git mediante la consolidación de archivos similares en paquetes. En el caso de los repositorios que se aproximan a los 250 GB, se puede alcanzar el límite interno en los archivos de paquete antes de que se complete el proceso de optimización. Cuando se alcanza este límite, los usuarios que intentan escribir en el repositorio ven el siguiente mensaje de error: "Se ha alcanzado el límite de archivos del paquete Git, las operaciones de escritura no están disponibles temporalmente mientras se actualiza el repositorio". Las operaciones de escritura se restauran inmediatamente después de que se complete el trabajo de optimización.

Los archivos no deben tener más de 100 MB. Este límite garantiza un rendimiento y una confiabilidad óptimos del repositorio de Git. Los archivos grandes pueden ralentizar significativamente las operaciones del repositorio, como la clonación, la captura y la inserción de cambios. Si necesita almacenar archivos grandes, considere la posibilidad de usar Git LFS (almacenamiento de archivos de gran tamaño), que está diseñado para controlar archivos grandes de forma eficaz almacenándolos fuera del repositorio principal y manteniendo solo las referencias a ellos dentro del repositorio. Este enfoque mantiene el rendimiento y la capacidad de administración del repositorio de Git.

Tamaño de inserción

Las inserciones de gran tamaño consumen recursos significativos, bloqueando o ralentizando otras partes del servicio. Estas inserciones a menudo no se alinean con las actividades típicas de desarrollo de software y pueden incluir elementos como resultados de compilación o imágenes de VM. Por lo tanto, las inserciones están limitadas a 5 GB a la vez.

Hay una excepción en la que las inserciones de gran tamaño son normales: al migrar un repositorio de otro servicio a Azure Repos. Estas migraciones se incluyen como una sola inserción y no pretendemos bloquear las importaciones, incluso para repositorios de gran tamaño. Si el repositorio supera los 5 GB, debe usar la web para importar el repositorio en lugar de la línea de comandos.

Tamaño de inserción de objetos LFS

Git LFS no cuenta para el límite de repositorio de 5 GB. El límite de 5 GB solo se aplica a los archivos del repositorio real, no a los blobs almacenados con LFS. Si encuentra inserciones con errores debido al límite de 5 GB, asegúrese de que el archivo .gitattributes incluye las extensiones de los archivos que pretende realizar el seguimiento con LFS. Asegúrese de que este archivo se guarda y almacena provisionalmente antes de realizar el seguimiento de los archivos grandes.

Longitud de la ruta de acceso

Azure Repos aplica una directiva de envío de cambios que limita la longitud de las rutas de acceso en un repositorio de Git al rechazar inserciones que introducen rutas de acceso excesivamente largas. A diferencia de la directiva Longitud máxima de la ruta de acceso, no se puede deshabilitar ni invalidar, ya que aplica los valores máximos admitidos por nuestra plataforma.

Se aplican los límites siguientes:

  • Longitud total de la ruta de acceso: 32.766 caracteres
  • Longitud del componente de ruta de acceso (nombre de archivo o carpeta): 4096 caracteres

Esta directiva solo afecta a las rutas de acceso recién introducidas en una inserción. No se aplica si se cambia un archivo existente, pero se aplica si se crea un nuevo archivo, se cambia el nombre o se mueve uno existente.

Si las confirmaciones que se insertan introducen rutas de acceso que superan estos límites, la inserción se rechaza con uno de los siguientes mensajes de error:

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