Administrar archivos binarios grandes con Git

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.

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.

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 .

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.

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.

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.

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.

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.

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).

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.

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?

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 .

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