We originally built GitLab with that use case of a single repo in mind. Create a GitLab project, and you have a single repository for code. We know this is an important use case for many teams, because of it's straightforward, simple scenario. It's something that's important to us, even as we expand to other use cases of multi-repo teams (groups/subgroups housing of projects). Thanks for the comment.
Re:Gitlab 9.0
by bryanlarsen on Wednesday March 22, 2017 @01:52PM
(#13933117)
Yup, I think Google & Facebook have this one right, a mono-repo is the way to go.
But there are advantages to multi-repos, especially if you're trying to share with clients and/or open source. You can have your cake and eat it too: we use https://github.com/splitsh/lite to update our micro-repos on every commit to our monorepo.
I've seen too many npm messes where people obsess over putting every button, dropdown, heading, and dumb image component in its own company-specific repo. Then they put the whole thing in a "UI kit" which realistically they will never reuse.