关于代码所有者

您选择的代码所有者必须拥有仓库的写入权限。当代码所有者是团队时，该团队必须是可见的，并且必须拥有写入权限，即使团队的所有成员已经通过组织成员身份或其他团队成员身份直接拥有写入权限。

关于代码所有者

当有人打开修改其拥有代码的拉取请求时，会自动请求代码所有者进行审查。代码所有者不会自动被请求审查草稿拉取请求。有关草稿拉取请求的更多信息，请参阅“关于拉取请求”。当您将草稿拉取请求标记为准备审查时，会自动通知代码所有者。如果您将拉取请求转换为草稿，则已订阅通知的人员不会自动取消订阅。有关更多信息，请参阅“更改拉取请求的阶段”。

当具有管理员或所有者权限的人员启用了强制审查时，他们还可以选择要求在作者合并存储库中的拉取请求之前获得代码所有者的批准。有关更多信息，请参阅“关于受保护的分支”。

如果文件有代码所有者，您可以在打开拉取请求之前查看代码所有者是谁。在存储库中，您可以浏览到该文件并将鼠标悬停在 上以查看包含代码所有权详细信息的工具提示。

CODEOWNERS 文件位置

要使用 CODEOWNERS 文件，请在存储库的 .github/、根目录或 docs/ 目录中创建名为 CODEOWNERS 的新文件，该文件位于您要添加代码所有者的分支中。如果 CODEOWNERS 文件存在于多个位置，GitHub 将按顺序搜索它们并使用找到的第一个文件。

每个 CODEOWNERS 文件为存储库中的单个分支分配代码所有者。因此，您可以为不同的分支分配不同的代码所有者，例如，为默认分支上的代码库分配 @octo-org/codeowners-team，为 gh-pages 分支上的 GitHub Pages 网站分配 @octocat。

为了使代码所有者收到审查请求，CODEOWNERS 文件必须位于拉取请求的基分支上。例如，如果您将 @octocat 作为存储库 gh-pages 分支上 .js 文件的代码所有者，那么当在头部分支和 gh-pages 之间打开对 .js 文件进行更改的拉取请求时，@octocat 将收到审查请求。

CODEOWNERS 和 fork

为了触发审查请求，拉取请求使用拉取请求基分支上的 CODEOWNERS 版本。基分支是拉取请求合并后将修改的分支。

如果您从 fork 创建拉取请求，并且基准分支位于上游存储库中，则拉取请求将使用上游存储库中该分支的 `CODEOWNERS` 文件。如果基准分支是您 fork 中的分支，则拉取请求将使用您 fork 中该分支的 `CODEOWNERS` 文件，但这只会触发代码所有者被专门添加到您的 fork 中的代码审查请求，并具有 `write` 访问权限。

当您将鼠标悬停在 上查看谁负责某个文件时，您将看到来自 `CODEOWNERS` 文件的信息，该文件位于您查看的任何存储库中的任何分支。

CODEOWNERS 文件大小

CODEOWNERS 文件的大小必须小于 3 MB。超过此限制的 CODEOWNERS 文件将不会加载，这意味着不会显示代码所有者信息，并且不会要求相应的代码所有者审查拉取请求中的更改。

要减小 CODEOWNERS 文件的大小，请考虑使用通配符模式将多个条目合并为一个条目。

CODEOWNERS 语法

CODEOWNERS 文件使用与 gitignore 文件中使用的规则基本相同的模式。该模式后跟一个或多个 GitHub 用户名或团队名称，使用标准的 `@username` 或 `@org/team-name` 格式。用户和团队必须对存储库具有明确的 `write` 访问权限，即使团队成员已经拥有访问权限。

如果您想使用相同的模式匹配两个或多个代码所有者，则所有代码所有者都必须在同一行上。如果代码所有者不在同一行上，则该模式只匹配最后提到的代码所有者。

在大多数情况下，您也可以通过已添加到其 GitHub.com 帐户中的电子邮件地址来引用用户，例如 `[email protected]`。您不能使用电子邮件地址来引用托管用户帐户。有关托管用户帐户的更多信息，请参阅 GitHub Enterprise Cloud 文档中的“关于企业托管用户”。

CODEOWNERS 路径区分大小写，因为 GitHub 使用区分大小写的文件系统。由于 CODEOWNERS 由 GitHub 评估，即使区分大小写的系统（例如 macOS）也必须在 CODEOWNERS 文件中使用大小写正确的路径和文件。

如果您的 CODEOWNERS 文件中的任何一行包含无效语法，该行将被跳过。当您在 GitHub.com 上的存储库中导航到 CODEOWNERS 文件时，您可以看到任何突出显示的错误。存储库的 CODEOWNERS 文件中的错误列表也可以通过 API 访问。有关更多信息，请参阅“存储库的 REST API 端点”。

CODEOWNERS 文件示例

# This is a comment.
# Each line is a file pattern followed by one or more owners.

# These owners will be the default owners for everything in
# the repo. Unless a later match takes precedence,
# @global-owner1 and @global-owner2 will be requested for
# review when someone opens a pull request.
*       @global-owner1 @global-owner2

# Order is important; the last matching pattern takes the most
# precedence. When someone opens a pull request that only
# modifies JS files, only @js-owner and not the global
# owner(s) will be requested for a review.
*.js    @js-owner #This is an inline comment.

# You can also use email addresses if you prefer. They'll be
# used to look up users just like we do for commit author
# emails.
*.go [email protected]

# Teams can be specified as code owners as well. Teams should
# be identified in the format @org/team-name. Teams must have
# explicit write access to the repository. In this example,
# the octocats team in the octo-org organization owns all .txt files.
*.txt @octo-org/octocats

# In this example, @doctocat owns any files in the build/logs
# directory at the root of the repository and any of its
# subdirectories.
/build/logs/ @doctocat

# The `docs/*` pattern will match files like
# `docs/getting-started.md` but not further nested files like
# `docs/build-app/troubleshooting.md`.
docs/*  [email protected]

# In this example, @octocat owns any file in an apps directory
# anywhere in your repository.
apps/ @octocat

# In this example, @doctocat owns any file in the `/docs`
# directory in the root of your repository and any of its
# subdirectories.
/docs/ @doctocat

# In this example, any change inside the `/scripts` directory
# will require approval from @doctocat or @octocat.
/scripts/ @doctocat @octocat

# In this example, @octocat owns any file in a `/logs` directory such as
# `/build/logs`, `/scripts/logs`, and `/deeply/nested/logs`. Any changes
# in a `/logs` directory will require approval from @octocat.
**/logs @octocat

# In this example, @octocat owns any file in the `/apps`
# directory in the root of your repository except for the `/apps/github`
# subdirectory, as its owners are left empty.
/apps/ @octocat
/apps/github

# In this example, @octocat owns any file in the `/apps`
# directory in the root of your repository except for the `/apps/github`
# subdirectory, as this subdirectory has its own owner @doctocat
/apps/ @octocat
/apps/github @doctocat

CODEOWNERS 和分支保护

存储库所有者可以更新分支保护规则，以确保更改的代码由更改文件的拥有者进行审查。编辑您的分支保护规则并启用“要求代码所有者审查”选项。有关更多信息，请参阅“关于受保护的分支”。

*.js     @global-owner1 @global-owner2

为了完全保护存储库免受未经授权的更改，您还需要为 CODEOWNERS 文件本身定义一个所有者。最安全的方法是在存储库的 .github 目录中定义一个 CODEOWNERS 文件，并将存储库所有者定义为 CODEOWNERS 文件（/.github/CODEOWNERS @owner_username）或整个目录（/.github/ @owner_username）的所有者。

作为分支保护规则或标签保护规则的替代方案，您可以创建规则集。规则集比分支和标签保护规则具有几个优势，例如状态，以及更好的可发现性，而无需管理员访问权限。您也可以同时应用多个规则集。有关更多信息，请参阅“关于规则集”。

进一步阅读

• "创建新文件"
• "邀请协作者加入个人存储库"
• "管理个人对组织存储库的访问权限"
• "管理团队对组织存储库的访问权限"
• "查看拉取请求审查"