At the moment of writing I have let’s say 4 micro services interoperating in order to build a bigger system.
Every microservice has its own repo.
What I’m thinking is that it would be useful to have parent repositories that group the children microservices, adding them as git submodules.
So if a developer needs to work and setup his dev env for:
systemA made of ms1, ms2,m3
systemB made of ms2, ms3, ms5
will just have to clone the system repository (already linking to ms dependencies)
Or if I need to build a new system , i’ll crete a new parent repository linking to git submodules ms dependencies
Basically the parent repo will contain nothing but link to submodules (don’t know if they will need some more at this moment.. )
For sure I’ll face the problem of having a ms development shared across different System. So maybe that would be solved using different master branche on children repo (one for every parent production system)
What do you think about this practice? Is it a good idea?
Working with submodules could become tricky?
4
Git submodules are broken:
- workflow is hard to follow
- history is cluttered
- unintuitive behaviour for non-git-experts
- easily broken (see section “Submodules break easily, and submodules break badly” here)
- they are loosely linked with the parent repo
We have been using them for something similar as you describe, and it is hell now. You modify a piece of code, and you’re not sure whether it will be the easy-to-commit-one, or the one that needs some acrobatics to push to the submodule, then update the reference in the parent repo and then push it. From time to time each of us spends hours trying to figure out what’s happening and why:
a) updating submodules (--recursive? --remote?) doesn’t update
b) git complains about changes, but committing them doesn’t commit them
c) you are stuck on a branch, unable to do anything until you resolve changes in submodules (stashing doesn’t work, nor other tricks to ignore changes)
Now, I admit – none of us is a git expert, and perhaps we do something wrong from time to time. However, most of us have no problem using advanced git features like rebase and we still cannot wrap our heads around “this submodules thing”.
I will not even continue my rant about what happens when you have submodules within submodules…
What seems a better solution is to create an internal package manager (in our case we have a NuGet server in our company).
To be honest: There are projects when submodules seem to work well, for example Qt.
The recommended use case, according to the documentation, is if you need the history to be separated when size is a problem and for controlling access.
5
There are tools to help you better manage multiple repos such as:
Meta
To clone an existing meta repo, you need only execute meta git clone
[meta repo url]. meta will clone your meta repo and all child
repositories at once. Creating a new feature that cross-cuts a number
of services, a site, and an API? Create new branches on all your repos
at once with meta git checkout -b [branch-name]. Or, revert all
modified files to their remote status with meta git checkout .
https://github.com/mateodelnorte/meta