Merging around 15 small Git repos of non-optional centralized web service components to a single large repo

Question

In a centralized web service we break down the components into various small Git repos by software modules, e.g. authentication module, authorization module, data access module etc. (around 15 repos at the moment)

The good thing is it is easy to manage the smaller code base, however, our productivity has decreased a lot since quite a lot of changes need to be update several repos at once.

Also, deployment is more difficult as there are multiple versions of module involved, we always need to think about the dependency.

I am considering to merge all the modules back to a single repo, because

• our services must require all the modules to exists, they are not optional for our service

• we are not a big team (3 people actually) and the overhead in maintaining too many repos does not worth it, they all need to have knowledge on all the code bases

What do you think? Any pros and cons if we merge into a giant repo?

Answer 1

This really depends on the modules. You are saying the service require all the modules to exist - but do the modules require the service(or other modules) to exist?

If you have a module that's an integral part of the project, but you have it as it's own module for organization reasons(example - models, views and controllers modules in MVC architecture), then it's a good idea to have them in same repository as the main project, because chances are they'll be updated together.

On the other hand, if you have a module that acts more like a library, and you could easily work on it as a standalone module and use it's functionality in other projects, it's better to keep it in it's own repository.

With 15 modules it's a safe bet that you have both kinds. You don't have to convert everything to a single repository. Maybe the main repository will consist of 10 modules, and another module will have it's own repository because it's a standalone library, and the other 4 modules are also a library, but need to be together to make sense so you put them all in a third repository. Of course, the distribution should not be arbitrary - it should be based on the logical coupling between the modules(not the current coupling - the one you think is the right design) - but at any rate you'll probably get a lower, more maintainable amount of modules.

Also, if you are having trouble keeping track of all the modules, you should consider using Git Submodules. Submodules allow you to keep the correct version of modules that reside in other repository, and you can commit and push directly from the submodule(be careful with this!). This should make working with many modules easier.