Hacker News new | past | comments | ask | show | jobs | submit login

> 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.




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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: