Pregunta Gestionar grandes archivos binarios con Git


Estoy buscando opiniones sobre cómo manejar grandes archivos binarios 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 en contra de esto, ya que aumenta la probabilidad de errores al configurar un nuevo sitio / migrar el anterior. Construye otro obstáculo para tomar.
  2. Administrarlos todos con Git.
    • Pro: Elimina la posibilidad de 'olvidar' copiar un archivo importante
    • Contras: hincha el repositorio y disminuye la flexibilidad para administrar la base de código y las cajas, clones, etc. llevará bastante tiempo.
  3. Repositorios separados
    • Pro: El control / clonación del 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 introduce algunas otras cosas en las que no había pensado.

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

Además: ¿Alguien tiene experiencia con múltiples repositorios Git y los está administrando 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.


507
2018-02-12 08:52


origen


Respuestas:


Si el programa no funciona sin los archivos, parece que dividirlos en un repositorio separado es una mala idea. Tenemos grandes suites de prueba 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 usar git-submodule para incorporarlos a su proyecto de una manera sensata. Por lo tanto, aún tendría el historial completo de todas sus fuentes, pero, según tengo entendido, solo tendría una revisión relevante de su submódulo de imágenes. los git-submodule La instalació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 un buen introducción a los submódulos de Git Book.


173
2018-02-12 14:29



yo 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 puede eliminarse del repositorio de Git, solo la jerarquía de árbol es rastreada por Git (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, por ejemplo:

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


305
2017-07-09 13:54



Otra solución, desde abril de 2015 es Almacenamiento de archivos grande de Git (LFS) (por GitHub).

Usa git-lfs (ver git-lfs.github.com) y probado con un servidor que lo soporte: lfs-test-server:
Puede almacenar metadatos solo en el repositorio git, y el archivo grande en otro lugar.

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


41
2018-04-09 05:53



Mira esto git bup que es una extensión de Git para almacenar inteligentemente binarios grandes en un repositorio de Git.

Querrá tenerlo como un submódulo, pero no tendrá que preocuparse de que el repositorio sea difícil de manejar. Uno de los casos de uso de muestra es el almacenamiento de imágenes 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.


29
2018-03-21 21:59



También puedes usar git-grasa. Me gusta que solo depende de stock Python y rsync. También es compatible con el flujo de trabajo habitual de Git, 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 su .gitattributes para especificar las extensiones de archivo que desea git fat administrar.

Agregas un binario usando la normal git add, que a su vez invoca git fat basado en tus reglas de gitattributes.

Finalmente, tiene la ventaja de que la ubicación donde se almacenan realmente sus binarios se puede compartir entre repositorios y usuarios y admite cualquier cosa rsync hace.

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


26
2017-09-26 04:51



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

Hace varios meses tuve un problema muy similar: ~ 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.

Usé 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 ... borrar 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-tree y git-commit-tree para crear una nueva confirmación, sin cometer ancestros, y se inició una nueva rama que apunta 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, borré los ref-logs y ejecuté "git prune": después de eso, mis carpetas .git solo ponderaron ~ 6 GB ...

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


21
2018-02-12 14:52



En mi opinión, si es probable que a menudo modifiques esos archivos grandes, o si tienes la intención de hacer un montón de git clone o git checkout, entonces debería considerar seriamente el uso de otro repositorio de Git (o tal vez otra forma de acceder a esos archivos).

Pero si trabajas como nosotros, y si tus archivos binarios no se modifican a menudo, entonces el primer clon / checkout será largo, pero después de eso debe ser tan rápido como quieras (teniendo en cuenta que tus usuarios siguen usando el primer repositorio clonado que tenido).


12
2018-02-12 09:12