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

Question

¿Alguien sabe cuáles son los límites de Git para la cantidad de archivos y el tamaño de los archivos?

Answer 1

Este mensaje de Linus himself le puede ayudar con algunos otros límites

[...] CVS, es decir, lo que realmente termina siendo más o menos orientada a un "un archivo a la vez" modelo.

cual es bueno en el que se puede tener un millón de archivos, y sólo comprobar a cabo algunos de ellos - usted nunca ve el impacto de los otros 999.995 archivos.

Git fundamentalmente nunca mira menos que todo el repositorio. Incluso si limita un poco las cosas (es decir, echa un vistazo a una parte o hace que el historial sea solo un poco), git termina por preocuparse por todo el asunto, y llevando el conocimiento.

Así que git escala muy mal si lo fuerza a mirar todo como uno enorme repositorio. No creo que esa parte sea realmente reparable, aunque es probable que la podamos mejorar.

Y sí, luego están los problemas del "archivo grande". Realmente no sé qué hacer con sobre archivos de gran tamaño. Nosotros los chupamos, lo sé.

ver más en mi other answer: el límite con Git es que cada repositorio debe representar un "coherent set of files", el "todos los sistemas" en sí mismo (no se puede etiquetar "parte de un repositorio").
Si su sistema está hecho de partes autónomas (pero interdependientes), debe usar submodules.

Como se ilustra en Talljoe's answer, el límite puede ser un sistema una (gran número de archivos), pero si lo hace entender la naturaleza de Git (alrededor de coherencia de datos representada por sus teclas SHA-1), se dará cuenta el verdadero "límite" es un uso uno: i.e, no intente almacenar todo en un repositorio de Git, a menos que esté preparado para obtener o etiquetar siempre todo de vuelta. Para algunos proyectos grandes, no tendría sentido.

---

Para un análisis más a fondo de los límites GIT, ver "git with large files"
(que menciona git-lfs:. Una solución para almacenar archivos de gran tamaño fuera del repositorio git GitHub, abril de 2015)

los tres problemas que limitan un repositorio git:

• archivos de gran tamaño (el xdelta for packfile está en la memoria solamente, que 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 pack a la vez.
• paquetes enormes, con un índice de archivo de paquete ineficaz para recuperar datos del (enorme) archivo de paquete.

---

Un hilo más reciente (febrero de 2015) ilustra the limiting factors for a Git repo:

Will unos clones simultáneas desde el servidor central también ralentizar otras operaciones simultáneas para otros usuarios?

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

Will 'git pull' ¿ser lento?

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

'git push'?

Éste no es afectado por la profundidad de la historia de tu repositorio es, o cómo amplia su árbol es, por lo que debe ser rápido ..

Ah el número de árbitros puede afectar tanto git-push y git-pull.
Creo que Stefan sabe más que yo en esta área.

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

Una vez más, el tamaño de su árbol. En el tamaño de su repositorio, no creo que deba preocuparse por eso.

Algunas operaciones pueden no parecer ser cotidianas, pero si se llaman con frecuencia por el front-end web a GitLab/Stash/GitHub, etc., pueden convertirse en cuellos de botella. (Por ejemplo, 'git branch --contains' parece terriblemente afectada adversamente por un gran número de ramas.)

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

Answer 2

No existe un límite real: todo se nombra con un nombre de 160 bits. El tamaño del archivo debe ser representable en un número de 64 bits, por lo que no hay límite real allí.

Sin embargo, hay un límite práctico. Tengo un repositorio que es ~ 8GB con> 880,000 y git gc toma un tiempo. El árbol de trabajo es bastante grande, por lo que las operaciones que inspeccionan todo el directorio de trabajo toman bastante tiempo. Sin embargo, este repositorio solo se usa para el almacenamiento de datos, por lo que solo se trata de un conjunto de herramientas automatizadas que lo manejan. La extracción de cambios del repositorio es mucho, mucho más rápida que sincronizar los mismos datos.

%find . -type f | wc -l 
791887 
%time git add . 
git add . 6.48s user 13.53s system 55% cpu 36.121 total 
%time git status 
# On branch master 
nothing to commit (working directory clean) 
git status 0.00s user 0.01s system 0% cpu 47.169 total 
%du -sh . 
29G  . 
%cd .git 
%du -sh . 
7.9G . 

Answer 3

Depende de lo que sea su significado. Hay límites de tamaño prácticos (si tiene muchos archivos grandes, puede ser aburrido). Si tiene muchos archivos, los escaneos también pueden ralentizarse.

Sin embargo, no existen límites inherentes al modelo. Ciertamente puedes usarlo pobremente y ser miserable.

Answer 4

Creo que es bueno para tratar de evitar el archivo de gran tamaño, comete como parte del repositorio (por ejemplo, un volcado de la base podría ser mejor en otro lugar), pero si se tiene en cuenta el tamaño del núcleo en su repositorio, probablemente pueda trabajar cómodamente con algo más pequeño y menos complejo que eso.

Answer 5

Si agrega archivos que son demasiado grandes (GB en mi caso, Cygwin, XP, 3 GB de RAM), espere esto.

fatal: Fuera de memoria, malloc no

Más detalles here

Actualización 3/2/11: Saw similares en Windows 7 x64 con la tortuga de Git. Toneladas de memoria utilizadas, respuesta muy lenta del sistema.

Answer 6

Tengo una cantidad generosa de datos que se almacenan en mi repositorio como fragmentos JSON individuales. Hay unos 75,000 archivos en unos pocos directorios y no es realmente perjudicial para el rendimiento.

La verificación en la primera vez fue, obviamente, un poco lenta.

Answer 7

git tiene un límite de 4G (32 bits) para el repositorio.

http://code.google.com/p/support/wiki/GitFAQ

Answer 8

Volver en febrero de 2012, hubo una muy interesante thread on the Git mailing list de Joshua Redstone, un ingeniero de software de Facebook pruebas Git en un gran repositorio de pruebas:

La cesión temporal de prueba tiene 4 millones de confirmaciones, historia lineal y aproximadamente 1.3 millones de archivos .

Las pruebas que se realizaron muestran que para un repo de este tipo, Git no se puede usar (operación en frío que dura unos minutos), pero esto puede cambiar en el futuro. Básicamente, el rendimiento se penaliza por el número de llamadas al stat() del módulo kernel FS, por lo que dependerá de la cantidad de archivos en el repositorio y de la eficacia del almacenamiento en caché de FS. Ver también this Gist para mayor discusión.

Answer 9

Encontré esto tratando de almacenar una gran cantidad de archivos (350k +) en un repositorio. Sí, almacenar. Risas.

$ time git add . 
git add . 333.67s user 244.26s system 14% cpu 1:06:48.63 total 

Los siguientes extractos del Bitbucket documentation son bastante interesantes.

Cuando trabajas con un clonaje de repositorio DVCS, presionando, estás trabajando con todo el repositorio y todo su historial. En la práctica, una vez que su repositorio supera los 500 MB, puede comenzar a ver problemas.

... El 94% de los clientes de Bitbucket tienen repositorios menores de 500MB. Tanto el kernel de Linux como Android tienen menos de 900 MB.

La solución recomendada en esa página es dividir su proyecto en trozos más pequeños.