GitHub拥有超过14000个代码库。其中不到一半具有明确的所有权。以下是我们如何在不到45天的时间里为每个活跃的代码库指定经过验证的所有者，归档其余部分，并使所有权成为后续工作的基础。2026年7月9日 | 9分钟分享：GitHub在我们的主要内部GitHub组织中拥有超过14000个代码库。截至2025年初，仍有超过11000个未归档的代码库，其中绝大多数没有明确的所有者。对于附属于生产服务的代码库，我们在历史上有健全的持久所有权，但对于没有相关服务的代码库，则没有可靠的方式来判断所有者。这个差距在我们进行秘密扫描补救工作时成为一个反复出现的问题：虽然我们在技术上能够轮换一个秘密，但在不知道代码库所有者的情况下这样做是有风险的，往往还会导致干扰，而且我们没有明确的方式来路由补救工作。在一个半月的时间里，我们验证了每个活跃代码库的所有权，归档了约8000个不再使用的代码库，并更改了代码库创建方式，以便从一开始就需要明确的所有权。我们的原始所有权模型多年来，GitHub通过我们的内部服务目录跟踪部署服务的所有权。每个服务条目记录了诸如其所在代码库、拥有团队、执行赞助商和支持信息等元数据。这是Repo Ownership应用程序的服务所有权条目的示例：-团队：github/repo-ownership-dev代码库： https://github.com/github/repo-ownership名称：repo-ownership种类：moda全名：Repo Ownership描述：在整个组织内强制执行代码库所有权的服务维护者：mrecachinas执行赞助者：stephanmiehe ... 拥有这些丰富的元数据使得服务中心流程成为可能，例如事件响应、值班路由、漏洞管理和合规性范围。不幸的是，这种关系是多对一的（即，一个服务只能与一个代码库相关联，而一个代码库可以有多个服务）。这意味着如果您从一个服务开始，您可以找到代码库及其所有者。但如果您从一个代码库开始并需要找到一个所有者，您必须进行反向查找，而这仅对最初与服务对应的代码库有效。这留下了一个显著的所有权缺口，包括团队代码库、文档代码库、内部工具、一位项目代码库、个人实验代码库以及任何其他没有支持部署服务的代码库。每次我们需要联系这些“无主”代码库的所有者时，都需要手动操作：检查提交历史、阅读README、在Slack上询问或根据代码库名称进行猜测。对于一次性的工作，这种模糊性令人烦恼，但可以管理。对于在整个组织中扩展的重复安全工作流程来说，这确实带来了风险。在我们的秘密扫描清理过程中，我们花了太多时间试图找到正确的所有者，然后才能就警报做出明智的决定。设计新的所有权模型从根本上讲，我们需要将代码库所有权作为一项优先属性。我们考虑将所有权存储在每个代码库中的专用文件中或在集中式代码库中维护它，但最终选择了GitHub自定义属性。这种方法提供了一种原生、有结构的、组织范围内可查询的方式来管理所有权。它还使我们能够根据所有权类型选择性地执行企业和组织的政策和规则。我们创建了两个自定义属性：ownership-type和ownership-name。ownership-type可以接受三个值：“服务目录”、“Hubber处理名”（Hubber是我们称呼GitHub员工的名称）和“团队”。这些涵盖了GitHub上代码库所有权的实际范围。一个代码库要么属于某项服务（有待值班团队和定义生命周期），要么属于团队（如共享文档代码库或内部工具），要么属于个人（如个人项目或实验）。ownership-name是一个带有轻微验证的文本字段。我们的GitHub应用程序验证了每个值：Hubber处理名与我们GitHub组织中的真实成员身份进行核对，团队在组织内存在并且至少有两个成员，服务目录条目与我们的服务目录本身进行确认。我们在格式上故意采取了宽松的态度。如果有人输入@my-team而不是my-team，我们也会接受。我们想让添加所有权变得无摩擦，并依靠健全的验证捕获无效条目，例如不存在的团队、前雇员和已停用的服务。第一天的覆盖在我们要求任何人执行任何操作之前，我们构建了从服务目录到代码库自定义属性的定期同步。每个支持已知服务的代码库都设置了其ownership-type。