It's much nicer to have everything you could ever need in one place, instead of having to know what is in what repo. Especially when you have versions that need to correspond in the different repos...
Another benefit (imo one of the biggest ones) is not having to constantly create releases across all your repos and manage their states when jumping around during development.
My previous job used a collection of about 6 repos for different services and such, and it was a constant struggle to ensure the correct versions were used in development - especially if you were working on a bigger feature that wasn't yet released but required "future" versions from other repositories.
Having everything together in the same repo is great if
- you don't care about tests that span multiple versions of the app (e.g. patterns of usage around database upgrades)
- you don't care about git bisect sessions that evaluate a new test against old versions of the app
- you never want to try the new app on the old infra or the old app on the new infra
- you're not worried about tests written by people not on your team whose failures indicate scenarios that don't require action on your part (but might require action on theirs).
But imagine the increased productivity of your devs if they only had to check out a single repo. Anyone has the same organization of projects on their machine. All tools are in one place...
It makes sense to have separate repos for things that don't interact. But when your modules or services do. Having them together cuts out some overhead.
At my current job we have this setup - one repo contains 14 different services. Admittedly there are still way more services than their need to be but having everything in one place helps to keep bit rot at bay, and it avoids the need to deploy and synchronise patches across multiple repos.
Yeah I agree! I used to commit everything into one repo, and I found I was wasting a lot of time downloading thousands of files and vm's etc when I only needed to work on say one component.
I think this structure lets you take either approach, needs some tweaking though for sure.
That's fair. I think the important thing is to be able to have multiple versions of portions of your repo and then be able to version that. A branch of branches, so to speak.
reply