Administrar archivos binarios grandes con Git

523

Estoy buscando opiniones sobre cómo manejar archivos binarios grandes de los que depende mi código fuente (aplicación web). Actualmente estamos discutiendo varias alternativas:

  1. Copie los archivos binarios a mano.
    • Pro: no estoy seguro.
    • Contra: Estoy totalmente en contra de esto, ya que aumenta la probabilidad de errores al configurar un nuevo sitio / migrar el antiguo. Construye otro obstáculo para tomar.
  2. Adminístralos a todos con Git .
    • Pro: elimina la posibilidad de "olvidar" copiar un archivo importante
    • Contra: Bloquea el repositorio y disminuye la flexibilidad para administrar la base de código y las comprobaciones, clones, etc. tardarán bastante.
  3. Repositorios separados.
    • Pro: retirar / clonar el código fuente es más rápido que nunca, y las imágenes se archivan correctamente en su propio repositorio.
    • Contra: elimina la sencillez de tener el único repositorio de Git en el proyecto. Seguramente presenta algunas otras cosas en las que no he pensado.

¿Cuáles son sus experiencias / pensamientos con respecto a esto?

Además: ¿Alguien tiene experiencia con múltiples repositorios Git y los administra en un solo proyecto?

Los archivos son imágenes de un programa que genera archivos PDF con esos archivos. Los archivos no cambiarán muy a menudo (como en años), pero son muy relevantes para un programa. El programa no funcionará sin los archivos.

Pi.
fuente
26
¿Qué pasa cuando la versión que controla el archivo binario es necesaria? Estoy pensando en equipos de artistas que trabajan en activos.
Dan
3
Si es necesario, debe equilibrar sus recursos disponibles (disco, ancho de banda, tiempo de CPU) con el beneficio que obtiene.
pi.
44
Tenga en cuenta que sin el bloqueo de archivos, git no es excelente cuando varias personas necesitan trabajar en el mismo archivo binario.
yoyo
1
Ver también el bup de archivo de respaldo basado en git .
VonC
1
Aquí están bestechvideos.com/tag/gitcasts
doughgle

Respuestas:

177

Si el programa no funciona sin los archivos, parece que dividirlos en un repositorio separado es una mala idea. Tenemos grandes conjuntos de pruebas que dividimos en un repositorio separado, pero esos son realmente archivos "auxiliares".

Sin embargo, es posible que pueda administrar los archivos en un repositorio separado y luego usarlos git-submodulepara incorporarlos a su proyecto de una manera sensata. Entonces, todavía tendría el historial completo de toda su fuente, pero, según tengo entendido, solo tendría la única revisión relevante de su submódulo de imágenes. La git-submoduleinstalación debería ayudarlo a mantener la versión correcta del código en línea con la versión correcta de las imágenes.

Aquí hay una buena introducción a los submódulos de Git Book.

Pat Notz
fuente
11
"Según tengo entendido, solo tendrías una revisión relevante del submódulo de tus imágenes". No creo que esto sea correcto.
Robin Green
22
En efecto. Un submódulo es un repositorio completo de Git, que está anidado dentro del repositorio principal. Conoce toda su historia. Podría comprometerse con menos frecuencia, pero si almacena las mismas cosas que tendría en el padre, tendrá los mismos problemas que el padre.
Cascabel
55
Esta es una solución bastante pobre si tiene archivos binarios grandes que están cambiando a intervalos regulares. Tenemos un repositorio que está horriblemente hinchado porque se almacena un nuevo archivo binario en cada compilación. Si no está en Windows, como se menciona a continuación, el Anexo es una buena solución. Si estás en Windows ... solo tendrás que seguir buscando.
AA Grapsas
44
Otro problema al tener archivos binarios grandes en el repositorio es el rendimiento. Git no fue diseñado para hacer frente a grandes archivos binarios y una vez que el tamaño del repositorio aumenta a 3G +, el rendimiento cae rápidamente. Esto significa que tener grandes binarios en el repositorio limita sus opciones de alojamiento.
zoul
Los submódulos pueden reducir los requisitos de transferencia de datos de pago si utiliza el submódulo de forma creativa: cuando desee actualizar el contenido del submódulo, cree un nuevo compromiso sin un padre y luego apunte el superproyecto (repositorio principal de git) al compromiso recién creado sin un padre. Lógicamente, esto crea un historial desconectado para el submódulo, pero a cambio, cualquier versión del submódulo es más fácil de transferir porque esa versión no tiene historial.
Mikko Rantalainen
310

Descubrí git-annex recientemente que me parece increíble. Fue diseñado para administrar archivos grandes de manera eficiente. Lo uso para mis colecciones de fotos / música (etc.). El desarrollo de git-annex es muy activo. El contenido de los archivos se puede eliminar del repositorio de Git, solo Git realiza un seguimiento de la jerarquía del árbol (a través de enlaces simbólicos). Sin embargo, para obtener el contenido del archivo, es necesario un segundo paso después de tirar / empujar, p.

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

Hay muchos comandos disponibles, y hay una gran documentación en el sitio web. Un paquete está disponible en Debian .

rafak
fuente
11
Whoa! ¡Vota por la genialidad! Esto implementa una idea que tuve recientemente, y mucho más. Está escrito en Haskell no menos. git-media es una buena alternativa, por cierto.
cdunn2001
33
Pero, Annex no es compatible con Windows. Lo cual es problemático para los desarrolladores de juegos.
AA Grapsas
77
Escuché que Steam está abandonando el soporte para Windows y está agregando soporte para Linux ...;) en serio, ¿qué tan difícil puede ser portar esto? Supongo que tu desarrollador promedio de juegos podría hacerlo.
Sam Watkins
44
@EstebanBrenes El verdadero factor decisivo es que en la configuración normal, los enlaces simbólicos de Windows requieren privilegios elevados para crear.
Laurens Holst
44
Acabo de encontrar esta página . Se lee que ahora también git annexestá disponible en Windows . Si alguien lo ha probado en Windows, ¡me gustaría saber sobre su experiencia!
Kouichi C. Nakamura
49

Otra solución, desde abril de 2015, es Git Large File Storage (LFS) (por GitHub).

Utiliza git-lfs (consulte git-lfs.github.com ) y se prueba con un servidor que lo admite: lfs-test-server :
puede almacenar metadatos solo en el repositorio de git y el archivo grande en otro lugar.

https://cloud.githubusercontent.com/assets/1319791/7051226/c4570828-ddf4-11e4-87eb-8fc165e5ece4.gif

VonC
fuente
3
lfs-test-serverse declara que no es para uso en producción. En realidad, estoy trabajando en el servidor de producción LFS ( github.com/artemkin/git-lfs-server ). Está en progreso, pero ya es útil, y lo estamos probando internamente.
Fecha
¿Puedes revisar versiones anteriores de dicho archivo binario usando git lfs?
mucaho
1
@mucaho Deberías: la sintaxis de git checkout no ha cambiado y el script lfs smudge aún debería llamarse.
VonC
31

Eche un vistazo a git bup, que es una extensión de Git para almacenar de forma inteligente binarios grandes en un repositorio de Git.

Desea tenerlo como un submódulo, pero no tendrá que preocuparse de que el repositorio sea difícil de manejar. Uno de sus casos de uso de muestra es almacenar imágenes de VM en Git.

En realidad, no he visto mejores tasas de compresión, pero mis repositorios no tienen binarios realmente grandes.

Su experiencia puede ser diferente.

sehe
fuente
3
bup proporciona almacenamiento (internamente usando archivos de paridad para redundancia y git para compresión, deduplicación e historial), pero no extiende git. git-annex es una extensión git que proporciona un back-end de almacenamiento bup .
Tobu
@Tobu cuando publiqué esto, el anexo git aún no existía (en los principales lanzamientos)
sehe
2
bup es definitivamente interesante para administrar archivos grandes. Quería señalar una diferencia en la interfaz de usuario: usa comandos bup fuera de cualquier contexto de repositorio, y git es un detalle de implementación.
Tobu
27

También puedes usar git-fat . Me gusta que solo depende del stock de Python y rsync. También es compatible con el flujo de trabajo Git habitual, con los siguientes comandos autoexplicativos:

git fat init
git fat push
git fat pull

Además, debe registrar un archivo .gitfat en su repositorio y modificar sus atributos .gitat para especificar las extensiones de archivo que desea git fatadministrar.

Agregue un binario usando el normal git add, que a su vez invoca en git fatfunción de sus reglas de atributos.

Finalmente, tiene la ventaja de que la ubicación donde se almacenan realmente sus archivos binarios se puede compartir entre repositorios y usuarios y admite todo lo que rsynchaga.

ACTUALIZACIÓN: No use git-fat si está usando un puente Git-SVN. Terminará eliminando los archivos binarios de su repositorio de Subversion. Sin embargo, si está utilizando un repositorio Git puro, funciona de maravilla.

Carl
fuente
26

Usaría submódulos (como Pat Notz) o dos repositorios distintos. Si modifica sus archivos binarios con demasiada frecuencia, trataría de minimizar el impacto del enorme repositorio que limpia el historial:

Tuve un problema muy similar hace varios meses: ~ 21 GB de archivos MP3, sin clasificar (nombres incorrectos, ID3 incorrectos, no sé si me gusta ese archivo MP3 o no ...), y replicado en tres computadoras.

Utilicé un disco duro externo con el repositorio principal de Git, y lo cloné en cada computadora. Luego, comencé a clasificarlos de la manera habitual (empujar, tirar, fusionar ... eliminar y renombrar muchas veces).

Al final, solo tenía ~ 6 GB de archivos MP3 y ~ 83 GB en el directorio .git. Solía git-write-treey git-commit-treepara crear una nueva confirmación, sin antepasados ​​de confirmación, y comencé una nueva rama que apuntaba a esa confirmación. El "registro de git" para esa rama solo mostró una confirmación.

Luego, eliminé la rama anterior, mantuve solo la nueva rama, eliminé los registros de referencia y ejecuté "git prune": después de eso, mis carpetas .git pesaron solo ~ 6 GB ...

Podrías "purgar" el enorme repositorio de vez en cuando de la misma manera: tu "git clone" será más rápido.

Daniel Fanjul
fuente
Hice algo similar una vez donde tuve que dividir un repositorio que fusioné accidentalmente en dos distintos. Interesante patrón de uso sin embargo. :)
pi.
1
¿Sería esto lo mismo que solo: rm -f .git; git init; git add. ; git commit -m "Trash la historia".
Pat Notz
1
Sí, es lo mismo solo en mi estuche mp3. Pero a veces no desea tocar sus ramas y etiquetas (sin reducción de espacio en los repositorios públicos) pero desea acelerar un "git clone / fetch / pull" de solo una rama (menos espacio para dedicar a eso) repositorios de sucursales).
Daniel Fanjul
13

La solución que me gustaría proponer se basa en ramas huérfanas y un ligero abuso del mecanismo de etiqueta, en lo sucesivo denominado * almacenamiento binario de etiquetas huérfanas (OTABS)

TL; DR 12-01-2017 Si puede usar el LFS de github o algún otro tercero, debería hacerlo. Si no puedes, sigue leyendo. Tenga en cuenta que esta solución es un truco y debe tratarse como tal.

Propiedades deseables de OTABS

  • es una solución pura de git and git only : realiza el trabajo sin ningún software de terceros (como git-annex) o infraestructura de terceros (como LFS de github).
  • almacena los archivos binarios de manera eficiente , es decir, no llena el historial de su repositorio.
  • git pulle git fetch, incluso, git fetch --allsiguen siendo eficientes en ancho de banda , es decir, no todos los binarios grandes se extraen del control remoto de forma predeterminada.
  • Funciona en Windows .
  • almacena todo en un solo repositorio git .
  • permite la eliminación de binarios obsoletos (a diferencia de bup).

Propiedades indeseables de OTABS

  • se vuelve git clonepotencialmente ineficiente (pero no necesariamente, dependiendo de su uso). Si implementa esta solución, es posible que tenga que aconsejar a sus colegas que la usen en git clone -b master --single-branch <url>lugar de hacerlo git clone. Esto se debe a que, por defecto, git clone literalmente clona todo el repositorio, incluidas las cosas en las que normalmente no querría desperdiciar su ancho de banda, como las confirmaciones sin referencia. Tomado de SO 4811434 .
  • hace que el git fetch <remote> --tagsancho de banda sea ineficiente, pero no necesariamente el almacenamiento sea ineficiente. Siempre puede aconsejar a sus colegas que no lo usen.
  • Tendrá que usar periódicamente un git gctruco para limpiar su repositorio de cualquier archivo que ya no desee.
  • no es tan eficiente como bup o git-bigfiles . Pero es, respectivamente, más adecuado para lo que está tratando de hacer y más listo para usar. Es probable que tenga problemas con cientos de miles de archivos pequeños o con archivos en el rango de gigabytes, pero siga leyendo para obtener soluciones.

Agregar los archivos binarios

Antes de comenzar, asegúrese de haber confirmado todos los cambios, su árbol de trabajo está actualizado y su índice no contiene ningún cambio no confirmado. Puede ser una buena idea empujar todas sus sucursales locales a su control remoto (github, etc.) en caso de que ocurra un desastre.

  1. Crea una nueva rama huérfana. git checkout --orphan binaryStuffHará el truco. Esto produce una rama que está completamente desconectada de cualquier otra rama, y ​​la primera confirmación que realizará en esta rama no tendrá padre, lo que la convertirá en una confirmación raíz.
  2. Limpia tu índice usando git rm --cached * .gitignore.
  3. Respira hondo y elimina todo el árbol de trabajo usando rm -fr * .gitignore. El .gitdirectorio interno permanecerá intacto porque el *comodín no coincide.
  4. Copie en su VeryBigBinary.exe, o su VeryHeavyDirectory /.
  5. Añádelo y & comprometelo.
  6. Ahora se vuelve complicado: si lo empuja al control remoto como una rama, todos sus desarrolladores lo descargarán la próxima vez que invoquen git fetchobstruyendo su conexión. Puede evitar esto presionando una etiqueta en lugar de una rama. Esto aún puede afectar el ancho de banda y el almacenamiento del sistema de archivos de su colega si tiene la costumbre de escribir git fetch <remote> --tags, pero siga leyendo para obtener una solución alternativa. Siga adelante ygit tag 1.0.0bin
  7. Empuja tu etiqueta de huérfano git push <remote> 1.0.0bin.
  8. Solo para que nunca empujes tu rama binaria por accidente, puedes eliminarla git branch -D binaryStuff. Su confirmación no se marcará para la recolección de basura, porque una etiqueta huérfana apuntando sobre ella 1.0.0bines suficiente para mantenerla viva.

Retirar el archivo binario

  1. ¿Cómo puedo (o mis colegas) obtener el VeryBigBinary.exe desprotegido en el árbol de trabajo actual? Si su rama de trabajo actual es, por ejemplo, maestra, simplemente puede git checkout 1.0.0bin -- VeryBigBinary.exe.
  2. Esto fallará si no tiene la etiqueta huérfana 1.0.0bindescargada, en cuyo caso deberá hacerlo de git fetch <remote> 1.0.0binantemano.
  3. Puede agregar el VeryBigBinary.exeen su maestro .gitignore, para que nadie en su equipo contamine la historia principal del proyecto con el binario por accidente.

Eliminar completamente el archivo binario

Si decide purgar por completo VeryBigBinary.exe de su repositorio local, su repositorio remoto y los repositorios de su colega, simplemente puede:

  1. Eliminar la etiqueta huérfana en el control remoto git push <remote> :refs/tags/1.0.0bin
  2. Elimine la etiqueta huérfana localmente (elimina todas las demás etiquetas sin referencia) git tag -l | xargs git tag -d && git fetch --tags. Tomado de SO 1841341 con ligera modificación.
  3. Use un truco git gc para eliminar su confirmación ahora sin referencia localmente. git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@". También eliminará todos los otros commits sin referencia. Tomado de SO 1904860
  4. Si es posible, repita el truco git gc en el control remoto. Es posible si está autohospedando su repositorio y podría no ser posible con algunos proveedores de git, como github o en algunos entornos corporativos. Si está alojando con un proveedor que no le da acceso ssh al control remoto, simplemente déjelo. Es posible que la infraestructura de su proveedor limpie su confirmación sin referencia en su propio momento dulce. Si se encuentra en un entorno corporativo, puede aconsejarle a su TI que ejecute un trabajo cronista recolectando su control remoto una vez por semana más o menos. Si lo hacen o no, no tendrá ningún impacto en su equipo en términos de ancho de banda y almacenamiento, siempre que aconseje a sus colegas que lo hagan siempre en git clone -b master --single-branch <url>lugar de hacerlo git clone.
  5. Todos sus colegas que desean deshacerse de las etiquetas huérfanas obsoletas solo necesitan aplicar los pasos 2-3.
  6. Luego puede repetir los pasos 1-8 de Agregar los archivos binarios para crear una nueva etiqueta huérfana 2.0.0bin. Si le preocupa que sus colegas escriban git fetch <remote> --tags, puede nombrarlo nuevamente 1.0.0bin. Esto asegurará que la próxima vez que busquen todas las etiquetas, las antiguas 1.0.0binno tengan referencia y se marquen para la recolección de basura posterior (utilizando el paso 3). Cuando intenta sobrescribir una etiqueta en el control remoto, debe usarla -fasí:git push -f <remote> <tagname>

Epílogo

  • OTABS no toca su maestro ni ninguna otra rama de desarrollo / código fuente. Los hashes de commit, toda la historia y el pequeño tamaño de estas ramas no se ven afectados. Si ya ha hinchado su historial de código fuente con archivos binarios, tendrá que limpiarlo como un trabajo separado. Este script puede ser útil.

  • Confirmado para trabajar en Windows con git-bash.

  • Es una buena idea aplicar un conjunto de trucos estándar para hacer que el almacenamiento de archivos binarios sea más eficiente. La ejecución frecuente de git gc(sin ningún argumento adicional) hace que git optimice el almacenamiento subyacente de sus archivos mediante el uso de deltas binarios. Sin embargo, si es improbable que sus archivos sigan siendo similares de commit a commit, puede desactivar por completo los deltas binarios. Además, dado que no tiene sentido comprimir archivos ya comprimidos o cifrados, como .zip, .jpg o .crypt, git le permite desactivar la compresión del almacenamiento subyacente. Desafortunadamente, es una configuración de todo o nada que también afecta su código fuente.

  • Es posible que desee realizar un script de partes de OTABS para permitir un uso más rápido. En particular, los pasos de guión 2-3 de Eliminar completamente archivos binarios en un updategancho git podrían dar una semántica convincente pero quizás peligrosa para git fetch ("buscar y eliminar todo lo que está desactualizado").

  • Es posible que desee omitir el paso 4 de Eliminar completamente los archivos binarios para mantener un historial completo de todos los cambios binarios en el control remoto a costa de la hinchazón del repositorio central. Los repositorios locales permanecerán esbeltos con el tiempo.

  • En el mundo Java, es posible combinar esta solución maven --offlinepara crear una compilación fuera de línea reproducible almacenada completamente en su control de versiones (es más fácil con Maven que con Gradle). En el mundo de Golang, es posible desarrollar esta solución para administrar su GOPATH en lugar de hacerlo go get. En el mundo de Python, es posible combinar esto con virtualenv para producir un entorno de desarrollo autónomo sin depender de servidores PyPi para cada compilación desde cero.

  • Si los archivos binarios cambian muy a menudo, al igual que los artefactos de construcción, que podría ser una buena idea para la escritura de una solución que almacena 5 versiones más recientes de los artefactos en las etiquetas huérfanas monday_bin, tuesday_bin, ..., friday_biny también una etiqueta huérfano para cada versión 1.7.8bin 2.0.0bin, etc. Puede rotar weekday_biny eliminar binarios antiguos a diario. De esta manera obtienes lo mejor de dos mundos: mantienes el historial completo de tu código fuente pero solo el historial relevante de tus dependencias binarias. También es muy fácil obtener los archivos binarios para una etiqueta determinada sin obtener el código fuente completo con todo su historial: git init && git remote add <name> <url> && git fetch <name> <tag>debería hacerlo por usted.

Adam Kurkiewicz
fuente
"Tienes que usar periódicamente git gc" - dejó de leer allí mismo. ¿Por qué alguien renunciaría a su último cinturón de seguridad en favor de algún truco?
user1643723
@ user1643723 git gcno es inseguro de ejecutar. Todas sus confirmaciones pendientes se mantendrán de forma segura en el disco duro durante al menos 30 días de forma predeterminada: git-scm.com/docs/git-gc
Adam Kurkiewicz
Gracias por el informe detallado. Quería probar esto como una forma de almacenar algunas dependencias binarias en mi repositorio de GitHub de tal manera que no se descarguen de forma predeterminada cuando alguien clona el repositorio, pero se pueden descargar manualmente y actualizar el repositorio local. Sin embargo, recibí un error en este paso: git push <remote> 1.0.0bin- remote: error: GH001: Large files detected. You may want to try Git Large File Storage. Parece que tal vez GitHub ya no es compatible con esto? El binario en cuestión tenía un tamaño de 100 MB.
user5359531
1
Para ser completamente honesto, si se le permite usar github para su trabajo, ¿qué le impide usar LFS? Los chicos de github han trabajado duro para crear este producto, e incluso lo están alojando para usted y su infraestructura está optimizada para usarlo. Este truco está destinado a situaciones en las que realmente no puedes usar LFS u otros terceros y buscas una solución de git puro.
Adam Kurkiewicz
También actualicé la respuesta para que quede más claro acerca de cuán hacky es esta solución en realidad.
Adam Kurkiewicz
13

En mi opinión, si es probable que modifique a menudo esos archivos grandes, o si tiene la intención de hacer mucho git cloneo git checkout, entonces debería considerar seriamente usar otro repositorio de Git (o tal vez otra forma de acceder a esos archivos).

Pero si trabaja como nosotros, y si sus archivos binarios no se modifican a menudo, entonces el primer clon / pago será largo, pero después de eso debería ser tan rápido como desee (teniendo en cuenta que sus usuarios siguen usando el primer repositorio clonado) tenía).

claf
fuente
13
Y, los repositorios separados no harán que el tiempo de pago sea más corto, ¡ya que aún debe verificar ambos repositorios!
Emil Sit
El repositorio separado @EmilSit podría hacer que el pago sea mucho más corto si limpia constantemente el historial del "repositorio binario". Además, los desarrolladores no se verían obligados a verificar ambos repositorios cada vez .
FabienAndre
¿Por qué no simplemente hacer que el script de compilación del módulo principal obtenga los archivos binarios del segundo repositorio, extrayéndolos uno por uno (como aquí: stackoverflow.com/questions/1125476/… ).
akauppi
1
Incluso si sus archivos binarios no se cambian con frecuencia, los archivos grandes aún pueden matar su flujo de trabajo si a menudo empuja ramas al repositorio con fines de colaboración.
Timo Reimann
9

SVN parece manejar deltas binarios de manera más eficiente que Git.

Tuve que decidir sobre un sistema de versiones para la documentación (archivos JPEG, archivos PDF y archivos .odt). Acabo de probar agregar un archivo JPEG y rotarlo 90 grados cuatro veces (para verificar la efectividad de los deltas binarios). El repositorio de Git creció un 400%. El repositorio de SVN creció solo un 11%.

Parece que SVN es mucho más eficiente con archivos binarios.

Entonces, mi elección es Git para el código fuente y SVN para archivos binarios como documentación.

Tony Diep
fuente
33
Solo necesitaba ejecutar "git gc" (reempaque y recolección de basura) después de agregar esos 4 archivos. Git no comprime inmediatamente todo el contenido agregado, por lo que tendrá una compresión de grupo de archivos (que es más eficiente en términos de tamaño) y no tendrá una desaceleración de comprimir por separado cada objeto agregado. Pero incluso sin "git gc", git habría hecho la compresión por ti eventualmente, de todos modos (después de notarlo, se han acumulado suficientes objetos desempaquetados).
ruiseñor
24
@jpierson Creé un repositorio git vacío y agregué (y comprometí) una imagen bmp completamente blanca con un tamaño de 41MB, esto resultó en un repositorio git total con un tamaño de 328KB. Después de a, git gcel tamaño total del repositorio git se redujo a 184 KB. Luego cambié un solo píxel de blanco a negro y comprometí este cambio, el tamaño total del repositorio git aumentó a 388 KB, y después de que git gcel tamaño del repositorio git total se redujo a 184 KB. Esto muestra que git es bastante bueno para comprimir y encontrar deltas de archivos binarios.
Tader
66
@jpierson Una nota al margen: acabo de comentar sobre los deltas binarios. Git se comerá toda su memoria e intercambiará si está administrando repositorios con archivos grandes (tamaño GB). Para esto, use git-annex (ya mencionado en otra respuesta) ...
Tader
12
@ JanDvorak: nadie lo ha mencionado, porque es completamente falso. Las copias de Subversion son baratas - svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html - en la mitad de la página.
Joris Timmermans
12
@Tader: tu prueba es mala. De hecho, lo que llama un archivo binario es (desde la perspectiva de git) más como un archivo de texto: el flujo de bits está alineado en bytes y hay diferencias significativas y localizadas que se deben realizar; después de todo, cambiar un píxel es básicamente equivalente a cambiar un carácter en un archivo de texto (¿y quién usa mapas de bits sin comprimir hoy en día?) Pruebe el mismo experimento con un pequeño video, imagen comprimida, máquina virtual, archivo zip o lo que sea, y encontrará ese git no trata eficientemente con el delta; de hecho es fundamentalmente imposible con datos incompresibles.
Eamon Nerbonne
4

git clone --filter de Git 2.19 + clones poco profundos

Esta nueva opción podría eventualmente convertirse en la solución final al problema del archivo binario, si los desarrolladores de Git y GitHub lo hacen lo suficientemente fácil de usar (lo que posiblemente todavía no hayan logrado para submódulos, por ejemplo).

En realidad, permite recuperar solo los archivos y directorios que desea para el servidor, y se introdujo junto con una extensión de protocolo remoto.

Con esto, primero podríamos hacer un clon superficial y luego automatizar qué blobs para buscar con el sistema de compilación para cada tipo de compilación.

Incluso ya existe una --filter=blob:limit<size>que permite limitar el tamaño máximo de blob para obtener.

He proporcionado un ejemplo mínimo detallado de cómo se ve la función: ¿Cómo clono un subdirectorio solo de un repositorio Git?

Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
fuente
2

Estoy buscando opiniones sobre cómo manejar archivos binarios grandes de los que depende mi código fuente (aplicación web). ¿Cuáles son sus experiencias / pensamientos con respecto a esto?

Personalmente, me he encontrado con fallas de sincronización con Git con algunos de mis hosts en la nube una vez que los datos binarios de mis aplicaciones web se ubicaron por encima de la marca de 3 GB . En ese momento, consideré BFT Repo Cleaner , pero me pareció un truco. Desde entonces, comencé a mantener los archivos fuera del ámbito de aplicación de Git, en su lugar, aproveché herramientas especialmente diseñadas como Amazon S3 para administrar archivos, versiones y copias de seguridad.

¿Alguien tiene experiencia con múltiples repositorios Git y administrarlos en un proyecto?

Si. Los temas de Hugo se manejan principalmente de esta manera. Es un poco kudgy, pero hace el trabajo.


Mi sugerencia es elegir la herramienta adecuada para el trabajo . Si es para una empresa y está administrando su línea de código en GitHub, pague el dinero y use Git-LFS. De lo contrario, podría explorar opciones más creativas, como el almacenamiento descentralizado y cifrado de archivos usando blockchain .

Las opciones adicionales a considerar incluyen Minio y s3cmd .

Josh Habdas
fuente
0

Echa un vistazo a camlistore . No está realmente basado en Git, pero me parece más apropiado para lo que tienes que hacer.

Hernan
fuente