Managing multiple git repositories together

First stop git submodule

Git submodule is quite simple but it falls short quite rapidly. As soon as you need anything but a basic reference, you will need to look somewhere else. Even though you can pull all together, they still remain separate repositories.

Options

There is a world of options, but two main options are:

• git-subtree: Even though it seems to do the same, it has more functionality packed (StackOverflow explanation). Looking at it in action (tutorial & demo) it has a level of integration between projects which you might like or even need.
• Google repo: For a simple project it seems to be an overkill, but definitely worth mentioning it as it is used for the 1000+ Android project repositories (see “Pull in Multiple Git Repositories With Repo” entry within the article).

Just to mention a couple more:

• Git Slave: Which didn’t seem to be quite popular right now.
• myrepos: This project doesn’t seem popular. Even though it has an extension for Drupal, it is written in Perl. Got to it reading this StackOverflow post.

And there are more (even paid ones), but these were the open-source ones I chose to show in the list.

I don’t recommend looking for more options. For anything that falls outside of git-submodule, git-subtree or GoogleRepo capacities, I would use things like:

• Docker environments and Docker-Compose to orchestrate the local environment.
• CI/CD approaches like using Jenkins to orchestrate and deploy remote environments.
• To have a testing environment like gitHub pipelines (or something similar).
• Using good old make to do the local orchestration (like OpenCommerce does).
• If you are using PHP/Composer you could use their VCS options.

There could also be an argument over the advantages of using a monorepo, but that’s a completely different strategy.

In summary, I would rather not use git for something that falls into CI/CD tools realm.

So many options!

I must say I like simple tools and solutions, when things get too convoluted or too heavy I start to wonder if I chose the right tools. With that in mind I tend to stay with the simplest tool possible until shown wrong. Plus in this case in particular and with so many CI/CD solutions, I think we shouldn’t overload git with too many responsibilities.

Even though it is not perfect, for now I will stay with submodule. As long as you have a simple setup and I’m comfortable managing the repos separately, I think it is the easiest solution. It is a bit annoying the way to need to pull all of them when you have subfolders:

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

But it works and it is simple to set up:

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

After that your root git folder will have a .gitmodules file with the sub module/s repository configuration.

That’s it, that file references the submodule and when cloning the project, all of the submodules will come together.