Las posibilidades dentro de git son: submodule y subtree. Pero hay otros sistemas de manejo de múltiples repositorios.

Manejando multiples repositorios git todos juntos

El sospechoso de siempre

git submodule es simple de usar, pero tiene sus limitaciones. En cuanto necesitemos algo más que una referencia básica, vamos a sentir que necesitamos una herramienta distinta. A pesar de poder traerlos todos juntos, cada repositorio seguirá siendo uno separado.

Opciones

Existen muchas, pero las dos más importantes son:

• git-subtree: Si bien parece hacer lo mismo, tiene mayor funcionalidad (explicación en StackOverflow). Si lo vemos en acción (tutorial y demo) tiene un nivel de integración entre los proyectos que podemos querer.
• Google repo: Esto permite manejar proyectos muy complicados y no lo recomendaría para cosas sencillas. No puedo dejar de mencionarlo ya que se usa para manejar los más de 1000 proyectos que componen Android (ver el título ”Pull in Multiple Git Repositories With Repo” dentro del artículo).

Solo por mencionar otros tenemos a:

• Git Slave: Que la verdad que no parece ser muy popular en este momento.
• myrepos: Este si bien no es popular, tiene una extensión para Drupal. Pero fue escrito en Perl. Llegué a él lleyendo este StackOverflow post.

Y hay bastantes más (incluso pagos), pero estos son los open-source que elijo mostrar.

Yo no recomiendo buscar más opciones. Para cualquier caso de uso que no podamos cubrir con git-submodule, git-subtree o GoogleRepo, mi recomendación sería usar cosas como:

• Ambientes de Docker con Docker-Compose para orquestar el ambiente local.
• Utilizar herramientas CI/CD como Jenkins para orquestar y desplegar a ambientes remotos.
• Tener ambientes de testing en gitHub con pipelines (o similares).
• Usar el archiconocido make para la orquestación local (como OpenCommerce lo hace).
• Si estamos usando PHP/Composer podemos usar sus opciones de integración VCS.

Existen otros que argumentaran las ventajas de usar un monorepo, pero esa es otra estrategia distinta.

En resumen, yo prefiero usar otro tipo de herramientas. No pedirle a git que maneje los aspectos de CI/CD.

¡Tantas opciones!

Como prefiero soluciones y herramientas simples, cuando las cosas se complican mucho o vuelven pesadas suelo preguntarme si estoy usando las herramientas correctas. Con eso en mente, prefiero quedarme con la solución más sencilla posible hasta que llegue a su límite de uso. Además debo agregar que, existiendo tantas soluciones CI/CD, me parece sobrecargar a git el pedirle este tipo de funcionalidades.

Con todo esto en mente y a pesar de sus limitaciones, para mi mini proyecto en particular prefiero seguir usando submodule. Mientras nuestras necesidades sean simples y estemos dispuestos a manejar los repositorios separadamente, nos va a alcanzar. Es un poco molesta la sintaxis para traer todas las subcarpetas:

git clone --recurse-submodules --remote-submodules --branch <your-branch> <repo-url>

Pero funciona y es muy sencillo de configurar:

git submodule add -b <branch> <URL-to-Git-repo>
git submodule init

Luego de correr esos comandos tendremos en el raiz de nuestro repositorio el archivo .gitmodules con la configuración de nuestro submódulo/s.

Eso es todo, ese archivo tiene la referencia al submódulo y cuando hagamos un clone (como detallo arriba) nos traerá todo el código junto (incluso si hay submódulos fuera del directorio raiz).