[ThePhysicist]

Does anyone here have experience using submodules to tie individual repositories together? We've been using this in our small startup (only a few developers) and so far it works nicely. It allows us to check out and develop repositories individually but at the same time maintain an exact dependency graph for our entire system. You can for example have a single repository that ties together different projects and has submodules that contain specific references e.g. to the frontend, backend and deployment repositories. You can then use this master repository e.g. for deployment and integration testing. Gitlab makes CI/CD in such a setup very easy and checks out submodules recursively during a build, even across groups.

The drawback is that not many people are familiar with submodules and they can be a bit tedious to set up, though working with a submodule is almost like working with a normal file in git. One danger is of course that branching between individual submodules can get messy. Another nuisance might be that you have to commit recursively, i.e. if you have one repository with a submodule to which you make changes you need to first commit these changes in the submodule and then create a new commit in the parent repository that adds the new version of the submodule. Maybe this is a good thing though as it forces you to commit changes individually in each submodule before committing a larger change into your main repository. In general I would avoid nesting submodules more than two levels deep, as this can quickly get confusing.

In the past I've also worked on a large mono-repositoriy and enjoyed it as well, just curious to hear if anybody has used submodules in a larger team.

[the_gipsy]

I have bad experiences with submodules. It was only one submodule just one level deep, and it only contained something like a convoluted configuration shared among multiple repos.

As you say, getting a change first into the child and then into the parent requires double PRs and testing. But that's the same as if you had it as a package dependency. Only that instead of a version, you have a sha1 which you never know what it is.

I prefer package dependency, because it forces you to explicitly make a release, where it should have passed PR and some integration tests. Also merge conflicts are clearer.

[zaphod12]

Yes, I have experience and it has always seemed a great idea with a handful of developers and then come back to be a disaster when the team scaled. They become a nightmare to keep everything properly up to date when you have a lot of people working on all of it. Git sub repos worked a bit better, but overall I really recommend submodules exclusively when the submoduled repo changes very infrequently.