Ask HN: How to handle 500+ repositories in GitHub?

430+ repos here, corporate setting, its not great but we use some custom scripts (validate users, groups, which repos are allowed to be public), strict documentation, and quarterly auditing. We have a lot of strict requirements around branch protections and the API for branch protections leaves a lot to be desired.

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.

My org has about 500 repos split across 3 orgs. There’s a “main” org, an OSS org, and then splinters for people who are willing to pay for and manage their own.

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.

For those who are in organizations that have near 500 repos, why do many? Is it shear size of the company, or is it organizing individual internal libraries into different repos (seems like good practice), or something else? I've only ever worked for small companies where we have max 5 real repos, and I work at a company with a mono repo right now.

Large scale systems are very interesting to me, but I have to say, I don't mind the mono repo.

RE: Topics, this is a feature I just found. What is the UX like when trying to find repos by topic?

Maybe take a variation of the old COBOL playbook to number things in an extensible way - prefix repo names so that they are organized by it.