Menu
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?
954
In most cases, Git submodules are used when your project becomes more complex, and while your project depends on the main Git repository, you might want to keep their change history separate. Using the above as an example, the Room repository depends on the House repository, but they operate separately.
we are to our monorepo customers who have collaborated with us to make GitHub better. Their help in reporting, and sometimes even diagnosing, problems was instrumental to addressing them.
Mono-repo favors consistency, whereas multi-repo focuses on decoupling. While in a mono-repo, the entire team can see changes done by one person, multi-repo creates a separate repo for each team, who have access to only the required services.
A monorepo removes barriers and silos between teams, making it easier to design and maintain sets of microservices that work well together. Standardization. With monorepos, it is easier to standardize code and tooling across the teams.
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.
112
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
