今日已更新 339 条资讯 | 累计 19899 条内容
关于我们

How GitHub gave every repository a durable owner

Michael Recachinas 2026年07月10日 00:29 3 次阅读 来源:GitHub Blog

GitHub had over 14,000 repositories. Fewer than half had clear ownership. Here's how we gave every active repository a validated owner in under 45 days, archived the rest, and made ownership the foundation for everything that followed. The post How GitHub gave every repository a durable owner appeared first on The GitHub Blog .

GitHub has over 14,000 repositories across our primary internal GitHub organization. As of early 2025, there were over 11,000 non-archived repositories, the vast majority of which with no clear owner. For repositories attached to production services, we have historically had robust durable ownership, but for repositories with no associated service, there was no reliable way to tell who the owner is. That gap became a recurring problem during our secret scanning remediation effort : while we could technically rotate a secret, doing so without knowing the repository owner was risky and often disruptive, and we had no clear way to route remediation work. Over the course of a month and a half, we validated ownership for every active repository, archived about 8,000 repositories that were no longer in use, and changed repository creation so that ownership was required from the start. Our original ownership model For years, GitHub has been tracking ownership for deployed services through our internal Service Catalog. Each service entry recorded metadata like which repository it lived in, which gave us a mapping from service to repository; the owning team; executive sponsor; and support information. Here’s an example of the Repo Ownership app’s service ownership entry: - team: github/repo-ownership-dev repo: https://github.com/github/repo-ownership name: repo-ownership kind: moda long_name: Repo Ownership description: Service enforcing repo ownership across the org maintainer: mrecachinas exec_sponsor: stephanmiehe ... Having this rich metadata enables service-centric workflows, such as incident response, on-call routing, vulnerability management, and compliance scoping. Unfortunately, that relationship was many-to-one (i.e., a service could only be attached to a single repository, but a single repository could have multiple services). That meant if you started from a service, you could find the repository and its owners. But if you started from a repository and needed to
本文内容来源于互联网,版权归原作者所有
查看原文