In a GitHub CODEOWNERS file, which rule applies when several patterns match the same file?

## The rule A GitHub `CODEOWNERS` file is a list of `<pattern> <owners…>` lines. To decide who owns a file, GitHub walks the file from top to bottom and keeps the **last** line whose pattern matches that path. That line's owners are the file's code owners. Every earlier match is discarded. Two consequences follow, and interviewers probe both: 1. **Order beats specificity.** A pattern is not "more authoritative" because it is longer or narrower. If `/docs/api/ @my-org/api-team` appears above `* @my-org/platform`, then `docs/api/index.md` is owned by the platform team, because the catch-all matched last. 2. **Ownership is not additive.** The winning line's owners replace, not extend, the previous ones. If you want two teams to both be able to approve a path, both must be named on the same winning line — and even then it is an *or*, since one approval from either satisfies it. ## The conventional ordering Because the last match wins, the file reads best from broadest to narrowest: a catch-all first, then directory rules, then the carve-outs. Reading downward, later lines carve exceptions out of earlier ones. Reversing the order would collapse the whole file into a single owner. This is also why an appended line is dangerous. The natural instinct when adding a rule is to append it at the end of the file; if that rule is broad, it silently steals ownership from every narrower rule above it. In a large file, teams review CODEOWNERS diffs specifically for lines added below existing rules. ## Per-file evaluation Ownership resolution happens per changed path, not per pull request. A pull request touching `docs/api/openapi.yaml`, `infra/main.tf` and `src/app.ts` under a typical file has three distinct owner sets. GitHub requests all of them, and if the branch requires review from code owners, the pull request stays blocked until each owned path has an approving review from one of *its* owners. One team cannot approve on behalf of another's files. This is the mechanism behind the familiar complaint that a wide-reaching change needs many sign-offs: it is not a special "big PR" rule, just per-file resolution applied to a diff that happens to cross ownership lines. ## Pattern matching itself The patterns use gitignore-style syntax, which affects what "matches" means before precedence is even considered: - `*` used alone as the whole pattern matches any file at any level. - A leading slash anchors to the repository root: `/build/` matches only the top-level `build` directory, while `build/` matches one at any depth. - A trailing slash means the directory and everything under it. - `docs/*` matches files **directly inside** `docs` but not inside its subdirectories — a frequent source of "why wasn't this owned?". Getting the pattern wrong produces the same symptom as getting the order wrong (the intended owner is not requested), so debugging usually means checking both: does the pattern match this path at all, and is it the *last* pattern that does? ## Interaction with enforcement Precedence only decides who is requested and whose approval counts. Whether an unapproved pull request can still merge is a separate setting on the target branch — required review from code owners, configured through branch protection or a repository ruleset. Without it, precedence still determines who gets the review request, but nothing blocks the merge. ## Reviewing a large file At monorepo scale the file grows to hundreds of lines, and the failure mode is subtle: a rule exists, looks right, and never fires because something below it matches too. Two habits help. First, keep the file sorted broad-to-narrow and enforce that in review. Second, when someone reports that the wrong team was asked, read the file **bottom-up** for the first line matching the path in question — that is the winner, and it is usually a catch-all someone appended months earlier.