skip to content

In GitHub, why doesn't adding someone to CODEOWNERS by itself stop a pull request from merging?

level: middleimportance: must knowfreq 62%

answer

  1. The file only routes reviewers
  2. Enforcement lives somewhere else
  3. A branch-level setting must be enabled
  4. Direct pushes and bypass actors remain

basics

~10 s

CODEOWNERS on its own only auto-requests reviewers when a pull request is opened. Blocking a merge requires enabling required review from Code Owners on the target branch, through branch protection or a repository ruleset.

solid answer

~50 s

By default CODEOWNERS is advisory: when a pull request is opened, GitHub reads the base branch's file and automatically **requests** the owners of every changed path. Nothing prevents anyone with write access from merging without those reviews. Enforcement is a separate control on the target branch — the "require review from Code Owners" option in a branch protection rule or the equivalent pull request rule in a repository ruleset. With it on, each owned changed path needs an approving review from one of its owners before merge is allowed. Two caveats matter in practice. The requirement only bites on pull requests, so unless the branch also requires a pull request, a direct push bypasses it entirely. And bypass actors or administrators, where configured, can still merge unapproved — the control is a policy, not a cryptographic gate.

go deeper

for a junior

Recall the split: the CODEOWNERS file gets the right people requested, and a separate branch setting is what makes their approval mandatory before merge.

for a middle

Explain the enforcement path precisely — required review from Code Owners on the target branch, per-file resolution of owners, and the fact that authors cannot approve their own pull request.

for a senior

Demonstrate the auditing instinct: check that a pull request is also required, review who can bypass, and verify the protection pattern matches the branches people actually target before calling the control effective.

for a principal

Own the policy design — where enforcement is defined (repository versus organization rulesets), how small the bypass set should be, and how you evidence that the control has actually been exercised rather than merely enabled.

## Two separate mechanisms People conflate two things that GitHub keeps apart: 1. **CODEOWNERS** — a file in the repository that maps path patterns to owners. Its only automatic effect is that opening a pull request causes GitHub to request reviews from the owners of the changed files. 2. **Required review from Code Owners** — a setting on the *branch*, configured either in a classic branch protection rule or as part of a repository or organization ruleset. This is what turns "was asked" into "cannot merge until they approve". Commit the file without the setting and you get routing: the right people are notified and appear as requested reviewers, and a determined author can still click merge. Enable the setting without a usable file and nothing is required, because no path has an owner. ## What the requirement actually demands With required code owner review enabled, GitHub resolves ownership per changed file (the last matching CODEOWNERS rule for each path wins) and demands an approving review from an owner of **each** owned path. A pull request spanning three teams' directories needs approvals covering all three; one team cannot approve for another's files. Files with no owner impose no requirement, which is why a repository with only narrow rules still merges freely for changes outside them. An approval from any member of an owning team satisfies that team's rule. The pull request author never counts: GitHub does not allow approving your own pull request, so an author who is the sole owner of a path cannot self-satisfy the requirement — someone else with ownership, or a bypass, has to unblock it. That is a deliberate property, and a real operational hazard for paths owned by one person. ## The gaps that make it a policy, not a guarantee - **It only applies to pull requests.** If the branch does not also require a pull request before merging, a user with write access can push straight to the branch and never encounter the requirement. Required code owner review without required pull requests is a common half-configuration. - **Bypass exists by design.** Classic branch protection has an option to allow specified actors to bypass, and a separate choice about whether administrators are included; rulesets express the same idea as bypass actors. Anyone in that set can merge without owner approval. Auditing who can bypass is as important as the rule itself. - **Approvals can go stale.** If the branch is configured to dismiss stale approvals when new commits are pushed, a code owner approval is dismissed on the next push and must be re-obtained. Without that option, an approval given early survives later commits — though GitHub will still request the owners of any newly touched paths. - **Ownership is resolved from the base branch's file**, so a pull request that rewrites CODEOWNERS is judged by the old rules. ## Rulesets and classic protection side by side GitHub currently offers two overlapping ways to express branch policy: classic branch protection rules and rulesets, which can be defined at repository or organization level, target branches by pattern, and be layered so several apply at once. Both can require code owner review, and both can coexist on the same branch; where they do, the effective policy is the union of the requirements, with bypass evaluated per ruleset. Practically this means "why is this pull request blocked?" may have more than one answer, and "we turned that off" is not proof, because another layer may still require it. ## What good looks like A repository that genuinely enforces ownership has all of: a valid CODEOWNERS file on the branch being protected, whose owners hold write access; a rule on that branch requiring a pull request before merging; required review from code owners on that same rule; a deliberately small, reviewed bypass list; and the CODEOWNERS file itself owned so ownership changes are reviewed. When an interviewer asks this question, they are usually checking whether you know that the file is the *routing* layer and the branch setting is the *enforcement* layer — and whether you will mention the direct-push and bypass gaps unprompted, since those are what turn a control that looks green in the settings UI into one that has never actually stopped anything.

  • Required code owner review is on, but changes still land unreviewed. What do you check first?
    Whether the branch also requires a pull request before merging — without that, a write-access user can push directly and never meet the rule. Then check the bypass list and administrator handling, and confirm the protection's branch pattern actually matches the branch people target. Finally confirm the CODEOWNERS rules resolve to owners with write access.
  • The sole owner of a path opens a pull request changing it. Who can approve?
    Not the author — GitHub does not permit approving your own pull request, so their ownership cannot satisfy the requirement. Another owner of that path must approve, which means widening the rule to a team, or someone with bypass permission merges without it. Single-person ownership is the underlying fault to fix.
  • Does required code owner review demand approval for every changed file?
    Only for files that resolve to an owner. Ownership is decided per file by the last matching rule, so a pull request needs an approving review from an owner of each owned path; unowned files impose nothing. That is why a change crossing several directories can require several independent approvals.

saying these in an interview costs you the question

  • Believing the CODEOWNERS file alone blocks merges
  • Forgetting that direct pushes skip pull request rules
  • Ignoring bypass actors and administrator overrides
  • Assuming an author's own ownership approves their PR
  • Thinking one approval covers all owned paths

context

resolving links…