6

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?

  • If a microservice has a list of dependencies you could just build a simple script which checks out all related services? – Luc Franken Jan 27 '17 at 9:24
  • This is not exactly the point. it's like the depedency management like it's done with composer. But here It's related to microservices. If you are working on more ms simultaneously ....it would be great to have a way to fetch 'em all to be able to contribute to the development... instead of fetchin every single repo.... – koalaok Feb 3 '17 at 10:51
  • Are you making a container for deployment? You may have taken the hype about docker replacing packaging too seriously, the apps should be binary packaged, and then'd be able to do this without gluing together the repos. You're in deep right now, once you it git submodules, something has almost always gone way off the deep end. Some piece of structure is missing. – J. M. Becker Nov 18 '17 at 21:45
9

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" in the link above)

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 commiting 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.

  • Wait, rebasing is an advanced git feature? It seems pretty simple to me – DeadMG Jan 27 '17 at 23:24
  • @DeadMG Which ones are advanced then? – BartoszKP Jan 28 '17 at 13:16
  • git is the only technology where I find it best to take advice from someone who is NOT a git expert. – ytoledano Nov 19 '17 at 21:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.