Our app is built in microservice architecture, one service one repo. We are exploring whether we should create a monorepo, as many companies are following this practice. There are plenty of discussions about the pros and cons for mono vs. many. If we want to find an alternative to allow us have some cons from both options, should we use git submodules to provide 'looks-alike' mono structure?
1 Answers
Yes, there is a lot of discussion about submodules being good / evil, but I tend to think that some are using them wrong. Just like hitting a nail with a sledgehammer and not expecting any drawbacks, just because they have similar names.
A few things to consider when using them:
They are entirely isolated between them and between the superproject. There will be no detailed history in the superproject of the commits made in the submodule, just the ones that updated it.
When you make a commit on a submodule, you need to push it, because you're in another repo. If you don't and you go to the superproject to update the submodule, you will end up with a reference to a commit that was not pushed. And this will lead to even more problems and confusion.
These are examples of situations I found very often and people complain about them, but I don't consider these as cons, just things that we need to be aware of so we can decide if it suits our project or not.
We're using it in a project that has another one embedded, more like a module. They are both developed separately, and from time to time we update the module to a new version, or just keep it at a certain one for compatibility reasons. We don't need to know who is working on the module, or what they made, we just want to know when they released a new version / fixed something.
Maybe someone with more experience will share it, we sure need it.
Related