One great thing about Git X-Modules is that it can create sequences of repositories, nested within each other as in a Russian doll. With it, you can make your development structure truly modular, going far beyond the "Monorepo vs. Multirepo" controversy.

Let's consider that you have three repositories - App1, App2 and a shared Library.

The first natural step is to add the shared Library as a module both to App1 and App2. Now each of these two repositories contains a directory, that is synchronized with the Library repository.

Note, that these are otherwise regular directories, not "linked repositories", like Git submodules!

Now let's consider that for some reason you want to combine all your repositories in a monorepo. So you create a new bare repository and add App1, App2 and Library to it as modules. As a result, the Monorepo has three folders, each of them synchronized with a different repository.

This creates a peculiar structure, where the Library code is present 6 times in 4 repositories! And changing the code in any of these places will push the updates to the other five (unless you created a one-way synchronization somewhere).

You don't have to do it in that order - you may create the Monorepo first, and then add Library directly to App1 and App2. The result will be the same.

There's no limit to the number of modules nested that way. Amazing, isn't it?

However, there is one slight limitation: you can create new modules to the repository, that is itself a module to another repository, but you can not create new modules inside the directory that is already a module.

Let's consider that you have a Monorepo with 3 modules - App1, App2 and Library, and you want to add Library directly to App1 and App2.

You can do it in the way shown above. What you can't do, is add Library as a module inside the directories that are synchronized with App1 and App2. That will break the whole setup - one directory can not be a module of two repositories at the same time.

But even with this limitation, Git X-Modules provide incompatible flexibility and means to create complex modular systems of multiple repositories, sharing the updates with each other. See for yourself!

  • No labels