GitHub 清理了 8000 个无人认领的仓库，代码所有权不是写个 CODEOWNERS 就够了
作者：林岚｜OC 技术编辑
林岚
据 GitHub 工程博客 介绍，其主要内部组织有超过 1.4 万个仓库。2025 年初，未归档仓库超过 1.1 万个，其中绝大多数没有可靠负责人。GitHub 用 45 天核验所有权，并在整治过程中归档了约 8000 个不再使用的仓库。
一句话结论：仓库所有权不是“谁最近提交过代码”，而是当密钥泄露、依赖出事或服务故障时，系统能否立即找到一个仍然存在、确实有责任处理的人或团队。
问题在一次 secret scanning 整改中暴露出来。安全团队可以检测并轮换泄露密钥，却不知道改变密钥会影响谁，也不知道告警应该派给哪个团队。查提交历史、读 README、在 Slack 里问人，对一个仓库还能应付，对上万个仓库就是不可扩展的安全风险。
GitHub 原本已经通过内部 Service Catalog 管理生产服务，能从服务找到团队、值班和对应仓库。但大量文档、内部工具、一次性实验和个人项目并不对应线上服务。从仓库反查负责人时，这个模型就出现空洞。
新方案把所有权做成仓库的一等属性。GitHub 使用组织级 custom properties，设置 ownership-type 和 ownership-name。负责人可以是服务目录条目、至少两人的团队，或一名仍在职员工。GitHub App 会验证名字是否真实存在，Kubernetes CronJob 定期扫描；已有服务目录先自动覆盖约 1500 个仓库，其余仓库再由人认领。
没有负责人怎么办？系统先创建 issue，给出 30 天宽限期，之后自动归档。归档是只读、停止 Actions，但不删除，因此需要时可以恢复。首轮结束后，GitHub 最终留下约 3000 个活跃仓库和 1.1 万个归档仓库，新的无主仓库会在一小时内被发现。
过程中发生的两个小事故比成功数字更值得学。首先，系统在周六启动，全球其他时区的员工立刻被突然出现的归档警告惊到；其次，一个被归档仓库原来接收 Datadog issue，归档后触发了告警。更危险的是，服务目录如果返回错误数据，自动化可能批量归档正常仓库。团队后来增加“低水位线”：单次动作数量超过保守阈值就停止执行并报警。
这也是为什么 CODEOWNERS 不完全等价。CODEOWNERS 适合指定评审人，但文件可能过时，个人可能离职，也不一定覆盖仓库生命周期。持久所有权需要组织级校验、创建时强制、持续扫描和可逆处置。
关键事实
- GitHub 内部主要组织有 1.4 万多个仓库。
- 整治期间归档约 8000 个仓库，最终约 3000 个活跃、1.1 万个归档。
- 所有权分为服务、团队和个人，并通过系统验证有效性。
- 自动化归档加入动作数量阈值，防止错误数据造成大规模事故。
OC 判断
“无人维护的代码”本身就是资产负债。它可能保留密钥、依赖和自动化权限，却没有人对告警负责。GitHub 的方案不复杂，价值在于把组织责任变成机器可查询、可验证、会持续失效检查的数据。
为什么重要
- 开发者：个人实验一旦被其他系统依赖，就应转交团队，而不是长期挂在个人名下。
- 企业：仓库治理需要和人员目录、服务目录、密钥扫描及离职流程连接。
- 用户：很多供应链事故并非没人检测到，而是检测后找不到能安全处理的人。
评论
围绕这篇文章补充信息、提出问题或分享观察。