Github tiene un límite en empujar archivo grande. Entonces, si desea enviar un archivo grande a su repositorio, debe usar Git LFS.
Sé que es una mala idea agregar un archivo binario en git repo. Pero si estoy usando gitlab en mi servidor y no hay límite de tamaño de archivo en un repositorio, y no me importa que el tamaño del repositorio sea muy grande en mi servidor. En esta condición, ¿cuál es la ventaja de git lfs?git clone o git checkout sera mas rapido?
Matthieu Moy
Una especificidad de Git (y otros sistemas distribuidos) en comparación con los sistemas centralizados es que cada repositorio contiene toda la historia del proyecto. Suponga que crea un archivo de 100 MB, lo modifica 100 veces de una manera que no se comprime bien. Terminará con un repositorio de 10 GB. Esto significa que cada clon descargará 10 GB de datos, consumirá 10 GB de espacio en disco en cada máquina en la que esté haciendo un clon. Lo que es aún más frustrante: aún tendría que descargar estos 10 GB de datos incluso si git rm los archivos grandes.
Poner archivos grandes en un sistema separado como git-lfs le permite almacenar solo punteros a cada versión del archivo en el repositorio, por lo tanto, cada clon solo descargará una pequeña parte de los datos para cada revisión. El pago descargará solo la versión que está utilizando, es decir, 100 MB en el ejemplo anterior. Como resultado, estaría usando espacio en disco en el servidor, pero ahorrando mucho ancho de banda y espacio en disco en el cliente.
Además de esto, el algoritmo utilizado por git gc (internamente, git repack) no siempre funciona bien con archivos grandes. Las versiones recientes de Git progresaron en esta área y debería funcionar razonablemente bien, pero el uso de un repositorio grande con archivos grandes puede causarle problemas (como no tener suficiente RAM para volver a empaquetar su repositorio).
-
Siempre dije que ralentizaba el repositorio con el tiempo, ¡pero este es un gran ejemplo concreto! ¡Gracias por mostrar cómo se combinan el tamaño y el consumo de recursos!
– CTS_AE
3 de mayo de 2019 a las 0:44
-
Entonces, ¿usar LFS solo es bueno si modifica esos archivos grandes con frecuencia? ¿Qué pasa si quiero mantener algunos paquetes de software en el repositorio que uso pero nunca modifico?
– sanjivgupta
12 de abril de 2020 a las 3:11
-
@sanjivgupta En ese escenario, LFS tendrá muy pocos beneficios. Si sigue el proceso de gitlfs, marcaría los archivos como binarios; entonces si se accede al archivo con
git diffevitará que se bloquee potencialmente debido a un archivo grande. Además, si decide actualizar uno de esos paquetes en el futuro, obtendrá los beneficios previstos de lfs al clonar solo las últimas versiones para la rama desde la que está clonando. Dicho todo esto, debe usar un administrador de paquetes para ese escenario siempre que sea posible.– Marcos Clark
22 de abril de 2020 a las 21:46
-
Hola. Estoy usando GIT LFS, pero cada vez que hago un cambio en la escena y lo confirmo, se guarda completo en GIT LFS (250 MB) y, por lo tanto, no puedo trabajar así. No entiendo qué ventaja tiene usar GIT LFS cuando las escenas de Unity se guardan como un todo y en equipos más grandes, eso requeriría terabytes de almacenamiento GITLAB.
– Adam Beňko
23 de diciembre de 2021 a las 10:42
¿Has comparado la velocidad de conexión?
– SOFe
23 de febrero de 2016 a las 10:52
No. Estoy tratando de resolverlo en principio.
– Sanster
23 de febrero de 2016 a las 11:55
Con git-lfs, la clonación será MUCHO más rápida. Pago un poco más, el tiempo para descargar los archivos puestos en lfs. Pero si REALMENTE necesita verificar algunos binarios, lfs es la forma de hacerlo.
– Felipe
23 de febrero de 2016 a las 18:17
atlassian.com/git/tutorials/git-lfs
– Benny
08/09/2017 a las 19:09
Debe distinguir claramente el caso de uso si los archivos grandes se modifican (muy) o solo activos estáticos en el repositorio. En caso de que un archivo grande solo se agregue una vez, nunca se modifique, no hay uso de LFS. En caso de que se modifiquen los archivos grandes, se aplicará la respuesta aceptada
– g.pickardou
5 de febrero de 2019 a las 16:46