3 ms·
Not that this is a solution everywhere, but I'm always telling people that single-repo is the way to go for an integrated team. My rule is that if your business
by microcolonel 10y ago
Not that this is a solution everywhere, but I'm always telling people that single-repo is the way to go for an integrated team. My rule is that if your business unit can reasonably control a codebase, and you have access to it, it should be in the same repo as your other codebases, full-stop.
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.
- bryanlarsen 10y agoYup, 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 https://github.com/splitsh/lite to update our micro-repos on every commit to our monorepo.
- victorwu 10y agoWe 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.