GitHub如何为每个仓库确立持久所有权

GitHub内部主要组织拥有超过14,000个仓库，截至2025年初，有11,000多个非归档仓库，其中绝大多数缺乏明确所有权。对于生产服务相关仓库，GitHub历史上已有健全的持久所有权机制，但对于无关联服务的仓库，无法可靠确定所有者。这一缺口在秘密扫描修复工作中成为反复出现的问题：虽然技术上可以轮换密钥，但在不知仓库所有者的情况下进行操作存在风险且常具破坏性，也缺乏明确的修复工作路由方式。在一个半月的时间内，GitHub为每个活跃仓库验证了所有权，将约8,000个不再使用的仓库归档，并从源头改变仓库创建流程，要求所有权成为创建的必要条件。过去，GitHub通过内部服务目录跟踪已部署服务的所有权，每个服务条目记录了仓库映射、所属团队、执行赞助商等元数据，支持事件响应、漏洞管理等以服务为中心的工作流。但这种多对一关系（一个服务仅关联一个仓库，一个仓库可包含多个服务）意味着从服务出发能找到仓库及其所有者，反之则仅对映射到服务的仓库有效，导致团队仓库、文档仓库、内部工具等非服务支持的仓库存在所有权缺口，每次联系这些“无主”仓库的所有者都需手动检查提交历史、README、在Slack询问或根据仓库名称猜测。为解决此问题，GitHub设计了新的所有权模型，将仓库所有权作为一级属性，选择使用GitHub自定义属性进行管理，因其提供原生、结构化且可在组织范围内查询的方式，并能根据所有权类型选择性执行企业和组织策略。新模型创建了“ownership-type”和“ownership-name”两个自定义属性，“ownership-type”接受“Service Catalog”“Hubber Handle”（GitHub员工）和“Team”三个值，分别对应服务支持的仓库、个人项目仓库和团队共享仓库；“ownership-name”为文本字段，由GitHub应用进行验证，包括检查Hubber Handle是否为组织成员、团队是否存在且至少有两名成员、服务目录条目是否有效等，并对格式采取宽容态度以减少添加所有权的摩擦。在推广前，GitHub通过从服务目录到仓库自定义属性的定期同步，自动为约1,500个服务支持的仓库设置了所有权类型和名称。推广阶段，GitHub构建了由Kubernetes CronJob支持的GitHub应用，首次运行因选在周六早晨而引发员工疑问，因全球分布的公司总有在线人员。30天宽限期后，未设置所有权的仓库被归档，归档具有可逆性和非破坏性，仅使仓库变为只读且停止GitHub Actions运行，如需恢复可通过简单方式解封并设置所有权。初始宽限期后， enforcement loop从30天缩短至1小时，新仓库若未设置所有权将立即被标记。推广过程中出现两个小内部事件：一是因归档未设置所有权的仓库导致Datadog监控工作流无法创建问题而触发警报，为此GitHub在所有权问题中@提及仓库管理员并分配所有有写权限的用户作为 fallback；二是服务目录返回 stale 或损坏数据的风险，为此添加了低水位线机制，若某次运行中要执行的归档或创建问题数量超过保守阈值，应用将中止并触发Datadog监控，且服务目录不可达时跳过其验证。最终，GitHub在45天内完成整个工作，活跃仓库约3,000个，归档仓库11,000个（初始约3,000个），许多新归档仓库多年无提交。为保持所有权机制，GitHub在所有仓库创建流程中强制要求设置所有权属性，并缩短所有权丢失后的标记时间至1小时。不同所有权类型具有各自的持久性特征，服务目录条目随服务生命周期变化，团队需至少一名成员且稳定性较好，个人Hubber Handle在员工离职时失效，此时其个人仓库通常应被归档。对于其他组织，GitHub建议使用自定义属性实现类似所有权模型，包括定义所有权分类、在组织级别创建自定义属性、同步服务目录或资产清单、在仓库创建时强制所有权设置、为现有仓库建立宽限期工作流、避免在周六首次执行 enforcement、从一开始就设计防护措施应对数据错误和通知丢失等情况。