Ask HN: How to handle 500+ repositories in GitHub?
27 points| voorloopnul | 4 years ago
Apparently Gitlab and Bitbucket give you a feature to group repositories into projects while Github is lacking something similar.
How companies using Github handle their repositories when there are 100's of them?
sverhagen|4 years ago
We end up telling our teams to use the different search functions to help in making sense of the madness: search by language (automatically detected by GitHub), team, type (forks or other), topics and names. We have a decent process to make sure the appropriate topics are set for repositories (we manage all non-forks through Terraform), and to make sure that names include a useful prefix. Though I don't think we'll ever stop debating the right prefixes for our repository names.
It's a "poor man's" ordeal, that's for sure. Organizations are probably the right way to go, if you can.
We're still in the move, so too soon to tell, but I am also wondering if we aren't worried about a non-issue. Because while Bitbucket has "groups", I don't think I have ever consciously used those groups while working in Bitbucket (nor have we ever set up the Bitbucket groups very well for our organization anyway).
dariusj18|4 years ago
prepend|4 years ago
For the main org, we have templates that projects typically follow where they include info in the readme for what group and individuals manage and we require that they add a tag for the specific center and encourage tags for projects.
So it’s sort of possible to search for a tag within the org to see all the projects but it’s janky and confusing.
Some groups create “housekeeping repos” that is just a repo with docs that link out and describe all their projects. They use repo instead of wiki as GitHub wikis are kind of a pain to manage (must have specific permissions and can’t just fork and send a PR). So that group uses the housekeeping repo as the link they give out to new team members, etc.
For the OSS org projects, we also have a portal repo that builds a github.io portal site that shows cards for each repo and allows searching and sorting. The OSS org doesn’t use the tagging scheme because the public doesn’t really know or care about our internal org names. We have about 175 projects in our OSS org.
Note, we also run GitLab community edition internally and actually have subgroups and stuff. But since GitLab requires internal network access GitHub use is growing since GitHub is in the cloud and doesn’t require VPN. The GitLab license costs are much higher than GitHub and not really compatible with our dev style. We have lots of non-devs and the ratio is probably 3:1 of non-dev:dev and GitLab makes us license everyone the same so we can’t pay $1000/year so a PM can update readmes and project cards.
szszrk|4 years ago
https://docs.github.com/en/organizations/collaborating-with-...
prepend|4 years ago
Gitlab allows groups under the org so you can have hierarchies common in org structures.
I wish GitHub would do this with suborgs. So I can have a “Foo” org for my company and then divisions or big projects can have suborgs. So all users are members of Foo and then also members of their particular groups.
This is sort of possible with Teams and permissions but is hard UX as there’s no way to just see all the repos in a suborg.
sfgweilr4f|4 years ago
Maybe there is a place for an "index" repo that holds a set of github pages that acts as an index into all the repos and groups them via that page instead of just using search.
prepend|4 years ago
I think most teams just know their repos and go to a small set of projects so don’t spend a lot of time browsing the org trying to find stuff.
brarsanmol|4 years ago
1) If you don't want to have access control on your repositories you can simply create a project and link it multiple repositories to it.
2) In a similar vein, another approach without access control is adding a topics to your repositories and then searching them in the GitHub search bar using *topic: your-topic".
3) Finally, if you need to have access controls or permissions on your repositories you can create teams and assign that team repositories.
I am not a professional or corporate user, so please forgive me if any of this not 100% accurate.
ecesena|4 years ago
On the monorepo, I learned a couple interesting things. For example with npm packages, even if you host multiple packages in a single monorepo you can still track dependents for each individual lib [1]. Well done Github.
[1] https://github.com/.../.../network/dependents
wdavidw|4 years ago
fruityrudy|4 years ago
tossaway9000|4 years ago
We've found that setting up new repos in a strictly documented manner has been the best way to approach it, we also have some github actions that run periodically to run some sanity checks across repos.
We're a terraform shop but we had countless issues with the terraform-github-provider but, maybe its improved the last year or so.
Also, Github has no "protections" around tagging, this really hurts us as we want to move to tags and releases for versioning but don't have a way to require multiple approvals before cutting an artifact that can be promoted so we have to wrap some customization and processes around it.
cik|4 years ago
prepend|4 years ago
noufalibrahim|4 years ago
shoo|4 years ago
e.g. if there are requirements related to tracking issues in some uniform way in software projects that have a many:many relationship with source repos, a possible solution is to use some other system for issue tracking, don't try to track issues in github.
If there's a requirement to uniformly configure access controls / branch protection etc to hundreds of git repos, you could use terraform or roll your own automation using the github API combined with whatever you can enforce at the github org level.
bramblerose|4 years ago
andrewstuart2|4 years ago
dbg31415|4 years ago
https://www.zenhub.com/
captn3m0|4 years ago
Unfortunately, no solutions for grouping them.
[0]: https://registry.terraform.io/providers/integrations/github/...
[1]: https://github.com/optile/ghconf
jjice|4 years ago
Large scale systems are very interesting to me, but I have to say, I don't mind the mono repo.
elboulangero|4 years ago
Sevii|4 years ago
ex repo name is: $OrgName + $ProjectName
Honestly, it is not a great solution because the org name has changed a few times and we have repos under 3-4 different naming schemes.
unknown|4 years ago
[deleted]
Mennny|4 years ago
rurban|4 years ago
I even have some crontab's to update all issues via git bug bridge locally, so that I don't need an internet connection to github.com to work on tickets. Clicks are not easily automated, so I avoid them for my workflows. Same for almost daily rebasing. (all feature and bugfix branches are automatically rebased to master, when master moves). This is 90% automatic.
All my repos are public, I pay nothing. I find that better than paying for it and keeping them private.
PaywallBuster|4 years ago
giantg2|4 years ago
markuman123|4 years ago