2011-04-22 20 views
28

He heredado un proyecto de tamaño mediano IOS - ~ 30.000 líneas de código - que tiene un número loco de recursos de imagen. Por supuesto, usamos Git/Github para scm. Actualmente, las imágenes se incluyen en el árbol de directorios y, por lo tanto, se integran en el repositorio, lo que hace que el desarrollo sea un gran dolor de cabeza.¿Cómo manejo las imágenes en un repositorio de Git?

Tenemos 4 desarrolladores en el proyecto, algunos virtuales. Se me ocurre mover las imágenes a Dropbox, consultarlas desde el proyecto de iOS y mantener las cosas en forma.

¿Alguien tiene un comentario sobre esta idea? ¿Qué haces con los archivos de imagen/video/audio en una configuración de Git scm?

+0

El número de líneas de código no dice nada. :) –

+1

por ejemplo, algunas personas prefieren abrir llaves en nuevas líneas, algunas usan muchas líneas vacías, algunas ponen sus nombres de funciones en la línea después del tipo de devolución, etc. etc ... –

Respuesta

21

Estaría bastante nervioso acerca de eso, en realidad; ¿Qué sucede si quieres actualizar una imagen y luego cambiar de opinión? ¿O qué pasa si necesitas construir una versión de mantenimiento con imágenes antiguas?

Si esto es realmente un problema, y ​​nunca he visto que esto sea realmente un problema en la práctica, pero tomaré su palabra, ¿por qué no usar solo un informe para las imágenes, otro para todo? ¿más? A continuación, puede ser perezoso sobre la sincronización de la imagen.

+0

Así trato con los activos de arte en Mercurial. Funciona bastante bien. –

+3

+1 por "¿Es realmente un problema?". – vcsjones

+1

@Ernest, el problema surge durante la vorágine de actividad que ocurre antes de enviar la aplicación a la App Store. Terminas con pantallas de Git shite volando por la pantalla, la mayoría de las cuales son inofensivas pero escondidas entre el lodo podrían ser algo importante. Es el desorden incesante que encuentro molesto y confuso. – dugla

13

Puede ser un poco de dolor a tratar, pero lo que he utilizado en el pasado son submodules de imágenes y medios de comunicación. De esta forma, puede desplegar solo su código sin obtener las imágenes si lo desea, pero aún puede mantener sus imágenes y medios sincronizados con su código. Cuando el historial de los submódulos sea demasiado grande, podríamos simplemente crear un nuevo repositorio sin el historial y cambiar el antiguo submódulo por el nuevo. De esa forma, las personas podrían estar sincronizadas con la última versión de los medios, sin tener que sacar todo el historial.

Frecuentemente se comenzaría con las pantallas verdes de nuestro video en el sub-módulo, por lo que podría desarrollar con el vídeo antes de que fuera en su forma definitiva, pero una vez que se composited, que rompería la historia submódulo y empujar a cabo una nuevo submódulo que tenía solo los videos compuestos. Eso evitó tener una copia extra de cada video, al tiempo que le permitía (con un poco de trabajo manual de intercambiar los submódulos) sacar la versión anterior si era necesario.

Los submódulos aumentarán la cantidad de trabajo que tendrá que hacer. Si desea realizar cambios en sus imágenes, debe cambiarlos en el submódulo, confirmarlo, presionarlo, luego ir al proyecto principal, confirmar el cambio al submódulo y presionarlo. Para casos simples puede escribir algunos scripts para hacer esto un poco más fácil, pero en casos más complicados como conflictos de fusión, será considerablemente más complicado que usar un solo proyecto para todo.

3

me parece git para ser la herramienta equivocada para el trabajo cuando se trata de lidiar con la fuente binaria.

Los activos finalizados que su software requiere para ser considerado "completo" se mantendrían mejor comprometidos en su repositorio, pero buscaría una solución alternativa para trabajar con una fuente de imagen real, como un archivo ai o psd.

Git ofrece poco o ningún beneficio para trabajar con estos archivos y como ha afirmado, se hincha el repositorio que afecta negativamente a las zonas donde git ofrece un beneficio real.

Yo mismo he considerado Dropbox, pero siento la necesidad de una solución más adaptada. Una que me permite sincronizar rápidamente entre computadoras, almacena automáticamente las últimas diez versiones más o menos, me permite preservar y nombrar versiones específicas y admite el bloqueo de archivos (Leer: evitar la necesidad de probar y fusionar archivos binarios). Esta es una herramienta diferente para un trabajo/flujo de trabajo diferente. Lamentablemente, no sé de su existencia, pero me gustaría ver que se convierta en realidad.

+0

solo obra final en el repositorio. No .psd de archivos .ai. – dugla

+0

Sí, en ese caso solo me quedaría en el informe o lamentaré más tarde: /. Puedes usar un submódulo de git (http://bit.ly/aDvmTJ) para contener la locura si realmente hay mucho. Además, haga una auditoría, lo que en realidad se está utilizando o brindando valor. Si resulta ser un montón de cosas de eliminación de basura. –

9

No lo he usado, pero hay un proyecto llamado git media que está diseñado para que sea más fácil trabajar con archivos binarios grandes como imágenes en git. Es de Scott Chacon, que es una especie de gran cosa en el mundo git, así que me imagino que probablemente funcione bastante bien.

0

Puede almacenar la imagen y los binarios mediante el sistema Subversion (SVN). Las imágenes y otros archivos binarios no van a cambiar muy a menudo, pero aún así puede recibir una notificación cuando esos archivos se cambien o se actualicen centralmente.

Git es mejor para versionar solo el código fuente y solo incluir códigos fuente en Github.

Subversion y Git juntos pueden darle una versión total de todas las cosas.

3

git-lfs parece ser una buena solución moderna a este problema. Realiza un seguimiento de los archivos como punteros de texto locales en su repositorio, mientras los almacena en un gran almacén de archivos externo. Esto es algo así como la solución subrepo, pero sin la necesidad de tanta intervención manual.

Por un lado, esto hace que dependa más de tener acceso a Internet; probablemente no podrá cambiar completamente entre sucursales si no puede acceder al archivador externo. Por otro lado, significa que no está descargando el historial completo de cada archivo binario al clonar un repositorio.

Es compatible con GitHub, Visual Studio Online y Bitbucket Server.

Cuestiones relacionadas