¿Cuáles son los límites de archivos en Git (número y tamaño)?

Este mensaje del propio Linus puede ayudarte con algunos otros límites.

[...] es decir, realmente termina estando más o menos orientado a un modelo de "un archivo a la vez".

Lo cual es bueno porque puedes tener un millón de archivos y luego solo revisar algunos de ellos; ni siquiera verás el impacto de los otros 999,995 archivos.

Básicamente, Git nunca mira menos que todo el repositorio. Incluso si limitas un poco las cosas (es decir, revisas solo una parte o haces que el historial retroceda un poco), git siempre termina preocupándose por todo el asunto y llevando el conocimiento a todas partes.

Entonces, git escala muy mal si lo obligas a mirar todo como un repositorio enorme . No creo que esa parte se pueda arreglar realmente, aunque probablemente podamos mejorarla.

Y sí, luego están los problemas de los "archivos grandes". Realmente no sé qué hacer con los archivos enormes. Los apestamos, lo sé.

Vea más en mi otra respuesta : el límite con Git es que cada repositorio debe representar un " conjunto coherente de archivos ", el "todo el sistema" en sí mismo (no puede etiquetar "parte de un repositorio").
Si su sistema está hecho de partes autónomas (pero interdependientes), debe usar submódulos .

Como lo ilustra la respuesta de Talljoe , el límite puede ser del sistema (gran cantidad de archivos), pero si comprende la naturaleza de Git (sobre la coherencia de los datos representada por sus claves SHA-1), se dará cuenta del verdadero "límite". es de uso : es decir, no debes intentar almacenar todo en un repositorio Git, a menos que estés preparado para recuperar o etiquetar todo siempre. Para algunos proyectos grandes, no tendría sentido.

Para obtener una visión más profunda de los límites de git, consulte " git con archivos grandes "
(que menciona git-lfs : una solución para almacenar archivos grandes fuera del repositorio de git. GitHub, abril de 2015).

Los tres problemas que limitan un repositorio de git:

• archivos grandes (el xdelta para packfile está solo en la memoria, lo cual no es bueno con archivos grandes)
• Gran cantidad de archivos , lo que significa, un archivo por blob, y git gc lento para generar un archivo de paquete a la vez.
• archivos de paquete enormes , con un índice de archivo de paquete ineficiente para recuperar datos del (enorme) archivo de paquete.

Un hilo más reciente (febrero de 2015) ilustra los factores limitantes para un repositorio de Git :

¿Algunos clones simultáneos del servidor central también ralentizarán otras operaciones simultáneas para otros usuarios?

No hay bloqueos en el servidor durante la clonación, por lo que, en teoría, la clonación no afecta otras operaciones. Sin embargo, la clonación puede consumir mucha memoria (y mucha CPU, a menos que active la función de mapa de bits de accesibilidad, lo cual debería hacer).

¿ Será ' git pull' lento?

Si excluimos el lado del servidor, el tamaño de su árbol es el factor principal , pero sus archivos de 25k deberían estar bien (Linux tiene archivos de 48k).

' git push'?

Este no se ve afectado por la profundidad del historial de su repositorio o el ancho de su árbol, por lo que debe ser rápido.

Ah, el número de árbitros puede afectar tanto git-pushcomo git-pull.
Creo que Stefan sabe mejor que yo en este ámbito.

' git commit'? (Aparece como lento en la referencia 3. ) ' git status'? (Lento de nuevo en la referencia 3, aunque no lo veo).
(también git-add)

Nuevamente, el tamaño de tu árbol. Con el tamaño de su repositorio, no creo que deba preocuparse por eso.

Es posible que algunas operaciones no parezcan del día a día, pero si el front-end web las llama con frecuencia a GitLab/Stash/GitHub, etc., pueden convertirse en cuellos de botella. (Por ejemplo, " git branch --contains" parece terriblemente afectado por un gran número de sucursales).

git-blamepodría ser lento cuando un archivo se modifica mucho.

Jun 12 '2009 04:06 VonC