¿Deben almacenarse las imágenes en un repositorio git?

Para un equipo distribuido que usa Git y Github como control de versión, ¿las imágenes también deberían almacenarse en el repositorio de git?

En su mayor parte, las imágenes no se cambiarán. La carpeta que los contiene solo aumentará de tamaño a medida que se agreguen imágenes. Una preocupación es que la carpeta de imágenes puede crecer a un gran tamaño con el tiempo mediante la combinación de imágenes grandes, o simplemente muchas de ellas.

¿Se considera esto una mejor práctica? ¿Qué otras alternativas existen para compartir archivos binarios necesarios en proyectos a los que un equipo distribuido puede acceder fácilmente?

¿Sus imágenes son originales o pueden ser recuperadas (garantizadas?) De otro lugar? ¿Son necesarios para enviar una unidad de software construida desde la fuente? Si son originales, necesitan una copia de seguridad. Póngalos en su control de revisión, si nunca cambian, la penalización de espacio es la misma que una copia de seguridad, y están donde los necesita.

¿Se pueden editar para cambiar la apariencia del software, accidental o intencionalmente? Sí, entonces DEBEN ser controlados de alguna manera, ¿por qué usar otra forma cuando ya tienes una solución perfecta? ¿Por qué introducir el control de versión "copiar y renombrar" desde la Edad Media?

He visto la obra de arte original de todo un proyecto irse "poof" cuando el disco duro MacBook del diseñador gráfico murió, todo porque alguien, con sabiduría infinita, decidió que "los binarios no pertenecen al control de revoluciones", y los diseñadores gráficos (al menos este ) no suelen ser buenos con las copias de seguridad.

Lo mismo se aplica a todos los archivos binarios que se ajustan a los criterios anteriores.

La única razón para no hacerlo es el espacio en disco. Me temo que a $ 100 / terabyte, esa excusa se está desgastando un poco.

¿Porque diablos no? :)

Guardar binarios se considera una mala práctica, sí, pero nunca me preocupé demasiado por las imágenes.

En el peor de los casos, si tiene toneladas, almacénelas en otro lugar o use elementos externos o una extensión para soporte binario. Y si las imágenes no se cambian con tanta frecuencia, ¿dónde está el problema? No obtendrás un gran delta gordo. Y si se eliminan con el tiempo, es solo su servidor el que sufre un poco de almacenamiento del historial, pero los clientes no verán nada.

En mi opinión, no debería preocuparse por eso, dado que no almacena GB de esos.

Sin embargo, lo que podría hacer es almacenar imágenes de "fuente": SVG, macros de LaTeX, etc. y obtener las imágenes finales generadas por su sistema de compilación. Probablemente sea aún mejor, si puedes. Si no, entonces no te molestes.

(Dicho todo esto, Git brilla para archivos de texto, pero no es el mejor VCS para imágenes. Danos más contexto y métricas si puedes)

Para obtener información adicional, puede consultar estas preguntas y respuestas:

• Almacenar archivos de imagen en SubVersion / Git
• Git vs SVN con archivos que no son de texto
• Administrar archivos binarios grandes con Git y Git-submodule

Esta pregunta es bastante antigua, pero esta es una pregunta común que surge cuando se trata de Git y hay cierto progreso en las soluciones modernas para almacenar archivos grandes en un repositorio de Git desde la última respuesta.

Para almacenar archivos grandes en Git existen los siguientes proyectos:

• git-annex : esto ha existido por un tiempo pero, francamente, su complejidad se interpone en el camino.
• git-media : no hay experiencia personal con este. Parece bastante complejo también.
• git-fit : un intento de crear un complemento más simple. Requiere almacenamiento S3. Si bien aprecio la simplicidad, mi principal preocupación con el complemento es que es bastante desconocido y mantenido por 1 persona (divulgación completa, soy el único otro confirmador en este momento y fue por un problema trivial).
• git-lfs : aunque no lo he usado mucho, parece ser el santo grial. Está respaldado por Github y está disponible en todos sus repositorios a partir de octubre de 2015 y pone la complejidad de la administración de archivos en el sitio que almacena sus repositorios. El único inconveniente es que esto es bastante nuevo, por lo que más allá de Github no hay mucho soporte, aunque Gitlab también tiene soporte , al igual que Gitea , y Bitbucket ha aludido a brindar soporte en el futuro .

TLDR: si puede, use git-lfs para almacenar imágenes u otros archivos binarios en git.

Todo "no almacenar binarios en el control de origen" se establece por una razón específica: si tiene código fuente que compila, no almacene la compilación real, sino solo el código fuente. Las imágenes y los activos visuales no tienen una "fuente", por lo que deben rastrearse en el control de versiones.

Creo que la forma recomendada con Git es usar un submódulo (introducido en Git 1.5.3) que es básicamente un repositorio separado que está asociado con el principal. Usted almacena sus imágenes (y otros activos binarios) en el submódulo. Esto puede verificarse con el repositorio principal o dejarse, dependiendo de lo que se requiera.

De http://book.git-scm.com/5_submodules.html

"El soporte de submódulos de Git permite que un repositorio contenga, como subdirectorio, un pago de un proyecto externo. Los submódulos mantienen su propia identidad; el soporte de submódulos solo almacena la ubicación del repositorio de submódulos y el ID de confirmación, por lo que otros desarrolladores que clonan el proyecto que contiene (" el superproyecto ") puede clonar fácilmente todos los submódulos en la misma revisión. Es posible realizar pagos parciales del superproyecto: puede decirle a Git que clone ninguno, algunos o todos los submódulos".

Además, el tamaño no debería ser un problema importante si las imágenes no cambian con frecuencia. También puede ejecutar comandos para podar / reducir el tamaño, como:

git gc
git gc-aggressive
git prune

Sí .

Digamos que lanzas la versión de software 1.0. Para la versión 2.0, decide rehacer todas las imágenes para que tengan sombras. Entonces haces esto y lanzas 2.0. Luego, algunos clientes que usan 1.0 y no pueden actualizar a 2.0 deciden que quieren el programa en otro idioma. Te dan $ 1G para hacerlo, así que dices seguro. Pero en una cultura diferente, algunas de sus imágenes no tienen sentido, por lo que debe cambiarlas ...

Si mantendría sus imágenes en el control de la fuente, esto es fácil, basado en 1.0 realiza cambios en las imágenes (entre otras cosas), compilación, lanzamiento. Si no los tuviera en el control de la fuente, sería mucho más difícil, ya que tendría que encontrar las imágenes antiguas, cambiarlas y luego construirlas.

Si es parte del Proyecto, tiene que estar en el VCS . La forma de lograr esto mejor puede depender del VCS o de cómo organice un proyecto. Tal vez un repositorio para los diseñadores, y solo los resultados en el repositorio del codificador, o solo las 'Fuentes de imagen' (una vez tuve un proyecto con solo un archivo .svg, y las imágenes se generaron a través de make / inscape cli).

Pero, si un VCS no puede manejar eso, o se vuelve inutilizable, diría que no es la herramienta adecuada para su trabajo.

Hasta ahora, no tuve problemas para poner cantidades 'habituales' de gráficos (maquetas, conceptos y gráficos de página) para proyectos web en git.

Debería almacenar sus imágenes en SCM: sí. Sin ninguna duda.

Debería almacenar sus imágenes en git: esto se vuelve más complicado.

git es muy bueno con los archivos de texto, pero por su propia naturaleza no es demasiado atractivo con los binarios. Tendrá problemas con el tamaño de los datos transferidos cuando clone o empuje, sus directorios .git crecerán y podría confundirse con la fusión (es decir, ¡cómo fusiona 2 imágenes!)

Una respuesta es usar submódulos, ya que esto significa que el vínculo entre su proyecto y las imágenes será más débil, por lo que no tendrá que administrar las imágenes como si fueran parte de su fuente, pero aún así mantenerlas controladas y no tener se preocupa por ramificarlos, suponiendo que el subproyecto es solo un repositorio 'plano' de datos que no pasa por la misma rotación durante el proceso de desarrollo habitual.

La otra respuesta es colocarlos en un proyecto diferente, nunca bifurcarlo, y asegurarse de que todos los que se comprometan con ese proyecto lo empujen inmediatamente, nunca permita que 2 personas cambien la misma versión del archivo, lo encontrará más difícil. aspecto como git no está diseñado para un flujo de trabajo no distribuido. Tendrá que usar métodos de comunicación anticuados para prever esta regla.

Una tercera respuesta es colocarlos en un SCM completamente diferente que esté mejor orientado a trabajar con imágenes.

Agregando a la respuesta de @ haylem, tenga en cuenta que el tamaño juega un factor importante en esto. Dependiendo del VCS, podría no funcionar bien con toneladas de imágenes. Cuando los clones o los grandes empujes comienzan a tomar toda la noche, entonces es realmente demasiado tarde ya que todas las imágenes ya están en su repositorio.

Planee imágenes grandes y crecimiento futuro. No quieres tener dos años en este proyecto y tener un "oh mierda, tal vez el repositorio es un poco demasiado grande".

Definitivamente estoy de acuerdo en que almacenarlos técnica y económicamente es factible. Pregunta como es "¿son estas imágenes parte del producto de envío o parte del contenido de un producto de envío?" No es que no pueda almacenar contenido en GIT (o cualquier otro VCS) sino que es un problema separado para un VCS separado.