How does the CODEOWNERS file interact with branch protection rules, and how would you design a CODEOWNERS strategy for a monorepo with five teams?

Think of CODEOWNERS in a monorepo like a hospital's operating room scheduling board. Each surgical suite (code directory) has a designated chief surgeon (owning team) who must sign off before any procedure (pull request) proceeds. The general administrator (default owner) covers anything that does not have a specialist assigned, but the neurosurgery chief (security-team) always has override authority on brain surgeries (auth modules) regardless of the general assignment. The board is read top to bottom, and the last specialist listed for a particular room is the one who gets paged.

The CODEOWNERS file uses a gitignore-style pattern syntax where each line maps a file glob to one or more GitHub users or teams. The critical rule is last-match-wins: GitHub scans the file top to bottom and uses the final matching pattern for each changed file. This means you must place your broadest catch-all pattern (like * @platform-team) at the very top and progressively more specific patterns below it. If you reverse this order, your specific rules get overwritten by the broad one. Teams are referenced using the @org/team-name syntax, and every referenced team must have at least read access to the repository. Individual users are referenced with @username. You can place the file in the root, .github/, or docs/ directory.

When GitHub evaluates a pull request, it checks which files changed, matches each file against CODEOWNERS patterns in the base branch (not the PR branch, which prevents authors from removing themselves as required reviewers), and compiles the set of required reviewing teams. If branch protection has Require review from Code Owners enabled, at least one member from each matched team must approve before the merge button activates. This evaluation is separate from the general required review count: you might require two general approvals plus code owner approval, meaning a PR touching payments code needs two reviews from anyone plus at least one from the payments-team. GitHub shows code owner review status with a distinct shield icon on the PR page, making it easy to see which owner approvals are still pending.

For a monorepo with five teams, a production-grade CODEOWNERS strategy might look like this: start with a default owner for anything unmatched, then assign frontend-team to src/web/ and all .tsx/.css files, backend-team to src/api/ and src/services/, data-team to src/pipelines/ and migrations/, sre-team to infrastructure/, k8s/, terraform/, Dockerfiles, and CI workflows, and security-team to src/auth/, src/crypto/, and any secrets-related configuration. Cross-cutting concerns like the CI pipeline (.github/workflows/) should be co-owned by sre-team and the team whose service the workflow deploys. The CODEOWNERS file itself should be owned by a platform-governance group so that teams cannot unilaterally remove their own review requirements. This strategy ensures that every PR, no matter how small, is automatically routed to the right domain experts without any human triage.

A major gotcha is orphaned patterns where the referenced team has been renamed, deleted, or lacks repository access. GitHub does not validate CODEOWNERS entries, so a typo like @org/fronted-team (missing the 'n') silently fails, and no review is requested for matching files, effectively removing the review gate. Use the GitHub CODEOWNERS syntax checker in the repository settings or run a periodic audit script that validates every team reference against the org's team list. Another pitfall is overly broad patterns that create review fatigue: if the sre-team owns * as the catch-all, they get review requests for every single PR, leading to rubber-stamp approvals. Keep the default owner to a small governance team and use specific patterns for everything else.