Continuando con esta mini serie, dejo las consideraciones y buenas prácticas que mencioné en el post previo.

Debe tenerse presente que el clonado de los repositorios como sub módulos sólo los incluye como una referencia dentro de otro pero no lo los mantiene al día con respecto al original, es decir, no como si se tratara de un fork donde el sistema de versionado nos indicará su estado con respecto al origen.

La otra alternativa, como sub árboles, implica que los archivos del otro repositorio se juntarán con el nuestro (se toma una fotografía y quedan congelados en el tiempo (hasta cierto punto). En resumen:

• Los sub módulos son apuntadores a commits específicos en otro repositorio, lo que significa que enlazan a una versión específica hasta que se actualice.
• Los sub árboles fusionan los archivos de un repositorio en otro, lo cual puede ser una alternativa más simple a los sub módulos pero no preserva el enlace al repositorio original de la misma manera.
• Tanto los sub módulos como los sub árboles requieren que la relación entre los repositorios se maneje manualmente.
• El repositorio que se incluya como sub módulo o sub árbol, como cualquier otro repositorio, necesita los permisos apropiados para acceder a él.

Utilizando estos métodos, el contenido del repositorio se agrega bajo un directorio de nuestra elección (como se ilustró en el post previo) dentro del repositorio padre. La principal diferencia con un fork es que no es posible enviar pull requests al repositorio original pero debe tenerse cuidado al crear ramas y trabajar con los archivos de los sub módulos pues si los permisos son muy laxos podemos afectar al repositorio original.

Para minimizar ese riesgo, una buena práctica es el crear una rama de nombre «local» en dichos entornos. ¿Por qué escribo «entornos»? Porque aunque estén dentro de otro repositorio, cada sub módulo posee su propio control de versiones. Esto deberá quedar claro con lo que se ejemplifica a continuación.

...
$ ls
EEML	EyPCD
$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
$ cd EE*
$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
$ cd ..
$ cd Ey*
$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
$ cd ..
$ git checkout -b local
Switched to a new branch 'local'
$ git status
On branch local
nothing to commit, working tree clean
$ ls
EEML	EyPCD
$ cd Ey*
$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
$ git checkout -b local1
Switched to a new branch 'local1'

$ git branch
* local1
  main
$ cd ..
$ cd EE*
$ git checkout -b local2
Switched to a new branch 'local2'
$ git branch
* local2
  master
$ cd ..
$ git branch
* local
  master
$ cd EyPCD
$ git branch
* local1
  main
$ cd ..
$ git branch
* local
  master
$ cd EE*
$ git branch
* local2
  master
$ cd ../Ey*
$ git branch
* local1
  main
$ cd ..
$ ls
EEML	EyPCD

Se ilustran los comandos y la salida a pantalla. Podrá verse que en cada sub módulo (que apunta a otro repositorio) hay una rama diferente (también lo refuerza el hecho de que las ramas principales aparecen en cada uno como main y master (éste último reminiscencia de un pasado en el que hablar del modelo «maestro-esclavo» no era políticamente incorrecto).

La idea de la creación de esas ramas locales es el que sólo existan en el equipo donde hemos recreado los repositorios y que las mantengamos así para que evitemos alterar los proyectos originales en un descuido. Una mera precaución.