Git y datos binarios

Question

Actualmente estoy empezando a usar git para mi sistema de control de versiones, sin embargo, realizo un poco de desarrollo de web/juegos que, por supuesto, requiere que se almacenen imágenes (datos binarios). Entonces, si mi comprensión es correcta si comprometo una imagen y ésta cambia 100 veces, si obtengo una copia nueva de ese repos, básicamente estaría revisando las 100 revisiones de ese archivo binario.

¿No es esto un problema con los repositorios de gran tamaño en los que las imágenes cambian con regularidad, pero la búsqueda inicial del repositorio no sería demasiado grande? ¿Alguien ha tenido algún problema con esto en el mundo real? He visto algunas alternativas, por ejemplo, el uso de submódulos y el mantenimiento de imágenes en un repositorio separado, pero esto solo mantiene la base de código más pequeña, el repositorio de imágenes aún sería enorme. Básicamente, me pregunto si hay una buena solución para esto.

Answer 1

No llamaría a eso "checkout", pero sí, la primera vez que obtenga el repositorio, siempre que los datos binarios sean enormes e incompresibles, van a ser lo que son: enormes. Y sí, dado que la ley de conservación todavía está vigente, dividirla en módulos no le ahorrará espacio y tiempo en la extracción inicial del repositorio.

Una posible solución sigue utilizando el repositorio por separado y la opción --depth al tirar de ella. Los repositorios poco profundos tienen algunas limitaciones, pero no recuerdo exactamente, ya que nunca lo usé. Verifica los documentos. La palabra clave es "superficial".

Editar: De git-clone(1):

Un repositorio superficial tiene una serie de limitaciones (no se puede clonar o ir a buscar de ella, ni empujar desde ni en él), pero es adecuado si son solo interesados ​​en la historia reciente de un proyecto grande con un largo historial, y querrían enviar revisiones como parches.

Answer 2

Desafortunadamente, git no está hecho para almacenar datos binarios. Debido a que se distribuye, usted extraerá todas las versiones de todos los archivos cada vez que lo clone. También se vuelve ridículamente difícil eliminar esos grandes archivos binarios del depósito de código. Más sobre eso aquí: (http://www.somethingorothersoft.com/2009/09/08/the-definitive-step-by-step-guide-on-how-to-delete-a-directory-permanently-from-git-on-widnows-for-dumbasses-like-myself/).

Recomendaría probarlo pero mantener los archivos binarios por separado del código (es decir, utilizando submódulos). En ese caso, si no funciona, puede usar otra solución sin reescribir todo el historial de su repositorio principal.

Answer 3

Lo que hago es crear directorios ignorados/desbloqueados, y sincronizar el directorio/directorios de imágenes usando otros sistemas que no son git (o simplemente copiar manualmente los cambios al directorio de imágenes una vez, cuando se habla de una gran cantidad de imágenes que no necesita mantener sincronizadas por completo).

Answer 4

Hay una discusión de almacenamiento de archivos grandes con GIT aquí: http://blog.deveo.com/storing-large-binary-files-in-git-repositories/

me encontré con esta cuestión de forma, como parte de mi investigación y pensé que me gustaría señalar a la gente a la entrada de blog que ya he revisado (alerta de spoiler, recomiendan git-annex para usuarios que no usan Windows). .