CODEOWNERS and Required Reviews

A CODEOWNERS file maps file paths to the people or teams responsible for them, so the right reviewers are requested automatically when a pull request touches their area. On its own it only suggests; combined with branch protection, an owner's approval becomes mandatory for changes in their part of the tree.

The whole file is a list of path patterns and owners, evaluated with one rule that trips people up constantly: the last matching line wins. Get the ordering and the team permissions right and ownership routes itself; get either wrong and the rule silently does nothing.

The CODEOWNERS File

The file lives at .github/CODEOWNERS (or the repo root, or docs/). Each line is a gitignore-style path pattern followed by one or more owners, written as @user or @org/team. Patterns are matched against changed paths, and the last line that matches a given path is the one that assigns its owners.

# Default owner for everything not matched below
*                    @org/maintainers

# Frontend code
/src/web/            @org/frontend

# A specific file overrides the directory rule above it
/src/web/auth.ts     @org/security

Auto-Request vs Required

By default, matching owners are added as requested reviewers automatically — helpful, but not blocking. The "Require review from Code Owners" setting in branch protection is what makes their approval mandatory: until an owner of every changed path approves, the merge button stays disabled.

This split is the single most important thing to understand: CODEOWNERS alone never enforces anything. It is the branch-protection toggle that turns a suggestion into a gate.

Teams as Owners

Assigning ownership to a team, @org/team, rather than an individual lets GitHub route the request to the team and, with code-review assignment enabled, load-balance it across available members. When someone goes on vacation or leaves, the team still owns the path and the review is not blocked on one person.

Precedence and Gotchas

Because the last matching rule wins, a broad pattern placed near the bottom of the file overrides every specific rule above it — a single * at the end quietly makes one team own everything. Order rules from general at the top to specific at the bottom so the most specific match applies. Paths that match no rule simply have no owner and no required review.

Validation

GitHub validates the file and shows problems in the repository's CODEOWNERS errors view. An invalid line — a typo in a pattern, or a team without write access — does not raise a loud failure; the rule is just silently dropped, leaving that path unowned. Checking the errors tab after every edit is how you catch a rule that has quietly stopped applying.