En el primer post de esta serie, mostré como podía responderse a la necesidad de poder incluir un repositorio no terminado (o del cual queremos conocer sus actualizaciones) en otro. Nótese y hay que remarcarlo, que no hablamos de un fork. No estamos haciendo un proyecto alternativo al repositorio original, simplemente queremos incluirle en otro de nuestra autoría para tenerlo de ejemplo o referencia al nuestro.

Claro, algunos dirán que es más simple y sencillo copiar los archivos de ese repositorio original o hacer un fork. Fork, puede ser la respuesta pero sólo si estamos dispuestos a crear otro repositorio a la par del nuestro y que con el tiempo perdamos la relación de este y el nuestro. Lo primero (copiar archivos) puede ser una respuesta (quizás la más común) congelando en el tiempo el material del cual partió nuestro aprendizaje (aunque no es del todo el caso pero este enlace puede ejemplificar el asunto). Pero, ¿qué pasa cuando el repositorio de nuestro material de aprendizaje aún está siendo refinado y enriquecido? Congelarlo en el tiempo sólo nos dejará material incompleto y es cuando consideramos el fork pero este será un directorio más a la par del que estamos formando.

Una tercer alternativa son estos sub árboles o sub módulos; una mejor respuesta, aunque no perfecta. Cada una tiene sus consideraciones. En un segundo post mostré como podemos tener ese otro respositorio como sub módulo, donde tenemos un entorno git separado (pero contenido en el nuestro) y las consideraciones a tener al respecto e ideas de lo que pueden ser buenas prácticas a adoptar. Finalmente, aquí agrego algunas instrucciones adicinales a lo ya mencionado sobre cómo proceder cuando se vuelve a clonar un repositorio que cuenta con sub módulos y se trabaja sobre éste.

Clonación e inicialización

• Una vez que el repositorio se ha clonado, antes de hacer algo se necesita ejecutar los dos comandos siguientes para obtener y actualizar el contenido de los sub módulos:

$ git submodule init
$ git submodule update

• Alternativamente, al momento de clonar el repositorio, se puede inicializar y actualizar los submódulos en ese instante usando la opción --recurse-submodules:

$ git clone --recurse-submodules <URL-del-repositorio>

Manteniendo los sub módulos Actualizados

Cuando hay cambios en el repositorio de un sub módulo, actualizar el repositorio principal, implica:

1. Navegar al directorio del submódulo:.

          $ cd <ruta-al-submódulo>

2. Obtener los últimos cambios para el submódulo, donde <rama> es el nombre de la rama a la que quieres actualizar, típicamente main o master.

          $ git pull origin <rama>

Pasarse a la raíz del repositorio principal y preparar los cambios del sub módulo:

          $ cd ..
          $ git add <ruta-al-submódulo>

3. Confirmar y empuja los cambios al repositorio principal.

          $ git commit -m "Actualizar submódulo"
          $ git push

Esto actualizará la referencia en el repositorio principal para apuntar al último commit en el submódulo. Cuando se actualizan los submódulos, se ajusta el commit al que apuntan en el repositorio principal. Este cambio necesita ser confirmado y empujado para que otros que clonen el repositorio reciban el contenido correcto del submódulo. En caso de que halla cambios en nuestro repositorio clonado y en el sub módulo, conviene primero registrar los del submódulo (como se ha indicado arriba) y entonces proceder con los del nuestro.

Manejando Submódulos Anidados

Si los submódulos tienen sus propios sub módulos (sub módulos anidados), hay que manejarlos con una iniciación y actualización recursiva:

$ git submodule update --init --recursive

Este comando asegurará que todos los submódulos anidados también sean inicializados y actualizados.