When a pull request changes a sensitive or specialized part of a repository, automatic reviewer assignment helps route it to the people or teams responsible for that area. A CODEOWNERS file maps file patterns to owners, so changed paths can trigger review requests. More than one reviewer may be required when changes are large or involve security vulnerabilities. section 5.4.3
Listing 5.13 An example of a CODEOWNERS file
# 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 JSX files, only @vittoriak and not the global # owner(s) will be requested for a review. *.jsx @vittoriak #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. *.py nico@example.com # 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 docwriters team in the dev-org organization owns all .md files. *.md @dev-org/docwriters # In this example, @nozomiw owns any files in the build/logs # directory at the root of the repository and any of its # subdirectories. /build/logs/ @nozomiw # The `docs/*` pattern will match files like # `docs/getting-started.md` but not further nested files like # `docs/build-app/troubleshooting.md`. docs/* docs@example.com # In this example, @pedrob owns any file in an apps directory # anywhere in your repository. apps/ @pedrob # In this example, @trangv owns any file in the `/docs` # directory in the root of your repository and any of its # subdirectories. /docs/ @trangv # In this example, any change inside the `/scripts` directory # will require approval from @ndidio or @waltera. /scripts/ @ndidio @waltera # In this example, @lucjar 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 @lucjar. **/logs @lucjar # In this example, @mirav 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/ @mirav /apps/github
Use the example to compare global ownership, specific file patterns, email addresses, comments, and team-based ownership. section 5.4.3
Configure the file with these practical decisions:
- Place it in the repository root, docs/, or .github/ directory, and keep it on the base branch that receives pull requests. section 5.4.3
- Start with a broad default owner when useful, then add narrower patterns; the last matching pattern takes precedence. section 5.4.3
- Choose individuals, email addresses, or teams as owners, depending on how responsibility is organized. section 5.4.3
The same ownership policy can be configured differently in other tools. Azure Repos and Bitbucket can express assignment rules through tool configuration; one example assigns Backend/Infrastructure to C# changes and React/Frontend to JSX, JavaScript, or CSS changes. section 5.4.3
