Aug 09

Se me han pasado las ganas de jugar con Git submodules

Sigo jugando con Git y lo siguiente que me apetecía probar era el tema de git submodule. Con ellos puedes construir un proyecto/repositorio de Git en el que algunos de los directorios son otros proyectos/repositorios de git. De esta forma tienes un "super repositorio" compuesto de varios pequeños repositorios (aparte de tener su propio código).

Me pongo a ello, a mirar en google cómo se hace y veo que es un poco liado. Finalmente este tutorial me quita las ganas de probarlo. Git tiene unas pequeñas restricciones que hace que la creación de módulos sea un poco laboriosa y "pesadita"

  • En un repositorio bare no se pueden hacer commits.
  • No se puede clonar como submodulo un repositorio vacío.
  • No se puede añadir un submodulo en un repositorio bare.
  • No se puede hacer push si el origin es un repositorio no bare

Con todo esto el proceso de creación es tan complicado como lo siguiente (puedo estar equivocado en algún detalle, sólo lo he leído, intentado probarlo rápidamente y desistido por ser algo pesado)

  • Creas los repositorios que harán de submodulos como repositorios normales (no bare) y haces algún commit en ellos (si es bare no puedes  hacer el commit)
  • Los clonas para convertirlos en bares, pero con git config tienes que tocar manualmente las referencias en la copia, para que el bare no tenga como origen el repositorio normal.
  • Creas el super repositorio como repositorio normal y haces algún commit en él.
  • Convertimos el super repositorio en bare haciendo otro clone y tocando nuevamente las referencias a mano con git config.
  • Hacemos otro clone más del super repositorio bare y entonces añadimos los submodulos en la copia. Hacemos commit y push al repositorio central.

y tras este "simple" proceso está más o menos listo, salvo el detalle de que si un segundo desarrollador clona el super repositorio, tiene que acordarse de ejecutar git submodule init y git submodule update para que los submodulos realmente se clonen … ¿cómo hacemos estos comandos en un hudson por ejemplo? ¿O hudson lo tiene controlado?

Y bueno, si sólo fuera el proceso de crearlos, aun se podía plantear hacerlo (eso se hace sólo una vez en la vida de cada proyecto y lo hace el que crea el repositorio, supuestamente una persona avezada en git). El problema son los "gotchas" que vienen en el tutorial anterior. Indica que siempre hay que acordarse de publicar los cambios en los submodulos ANTES que los cambios en el superproyecto. Me hace a mí que en un grupo relativamente grande de desarrolladores, alguno se va a equivocar con bastante frecuencia. Aunque todo es cuestión de aprender el truco y convertirlo en hábito : "siempre commit y push de los submódulos primero".

Está bien saber que existen los submodulos de git por si algún día hacen falta. De hecho, trabajando en java es algo que echo de menos cuando tenemos muchos proyectos independientes pero que comparten juegos de ficheros no java comunes. Por ejemplo, juegos de iconos, dlls de windows, ficheros de script o ficheros de configuración (xml, properties, etc). La solución de "copiar" todo ese juego de ficheros en cada proyecto es un poco pesada, pero si no se copia es dificil hacer automáticamente un zip de instalación que tenga todos esos ficheros. La solución que se me ocurre es hacer un repositorio git con todo ese juego de ficheros y añadirlo como submodulo en los proyectos que lo necesiten.

En cualquier caso, queda pendiente para más adelante. Ahora me he puesto a jugar con Spring Framework WEB/MVC 😉

Entradas relacionadas:

Leave a Reply