[luikore]

One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry.

Some people are eager to divide their project into multiple repos in spite of git being a distributed version control system. Having many teams doesn't mean you should have many repos. Why not just let your team work on one small directory inside the repo?

[kareemm]

> One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry.

I think this depends on your job function. At Codetree we have a bunch of customers who need to see a project that spans multiple GitHub repos. The person who needs this view is the person responsible for delivery - usually a project manager, a product manager, or a dev manager.

A common example is a project that spans an API repo, a front end repo, and a mobile repo. If you're responsible for delivery, you want to be able to answer questions like "How much work is left to deliver the FooBar feature", or "Show me all the tickets assigned to Joe". To answer these, you must see issues from multiple repos rolled up into a single view.

[luikore]

I suggest you use one repo with sub directories, one directory for API part, one directory for front end part, one for the server part ...

Then, when you change the API, you don't have to create 3 pull requests across 3 repos, just ONE pull request and teams can review all the changes together.

And your problem of searching for issues assigned to one person across multiple repos is not a problem any more.

There are already many good examples of managing multiple modules inside one repo:

https://github.com/apache/thrift

https://github.com/rails/rails

[TeMPOraL]

I think such cases call for a more professional / serious project management tool. I mean, GitHub projects is just a webapp, one that lets you move some rectangles around with a mouse. I'll be happily using it to manage issues on my small open-source projects (that incidentally are usually self-contained within a single repo), but for anything bigger / more serious, I'd rather use an external tool.

[PeterisP]

Reusable and reused components span multiple projects and even companies. A quite reasonable scenario is when a project includes a component library that's loosely coupled, open-sourced and used by others (so it pretty much has to be in a separate), but it's not just an included dependency but being actively worked on in a project - e.g. a single small new feature would require commits to both the library and the repository that's using it.

[kalleboo]

Client/Server is one case where I think having multiple repos under one project makes a lot of sense.

Another one is where we have forks of libraries with minor patches to suit our needs.

[fredsir]

Multiple codebases for multiple platforms also deserve multiple repositories.

[kalleboo]

Agreed. Depending on how much code is shared it could be one repo, or n+1 (n=platforms 1=shared code)

[empath75]

https://github.com/spinnaker

Spinnaker is comprised of a bunch of quasi-independent microservices, designed to work together. I don't think it would necessarily make sense to have them all in the same repo, when they could be swapped out or even used separately in another project.