Approvals and required reviewers — the gate, CODEOWNERS, and the audit

An approval is a reviewer’s assertion that they have read the change and consider it safe to merge. The forge tracks approvals per PR, attributes each to a user and a timestamp, and uses the count plus CODEOWNERS coverage to decide whether the merge button is enabled. The approval is the audit answer to “who said this was OK?”; the bypass is the answer to “who decided the rule did not apply?”.

The approval gate

A protected branch declares how many approvals a PR needs and from whom. Infrastructure teams typically require two approvals, one from a CODEOWNER of the changed paths, and one from someone other than the PR author.

gh pr review 123 --approve
gh pr review 123 --request-changes
gh pr review 123 --comment

An approval is not permanent. If new commits are pushed after the approval, most forges dismiss the stale approval — the reviewer approved a version that no longer exists.

flowchart LR
    A["commit a"] --> B["commit b"]
    B --> C["commit c"]
    C --> D["commit d"]
    P["approval on a..c"] -. "dismissed after push of d" .-> D
    P2["new approval on a..d"] --> D

CODEOWNERS

CODEOWNERS is a file in the repository that maps paths to owners. When a PR changes a path, the forge identifies the owners and requires an approval from each group whose path matches.

# .github/CODEOWNERS
/iam/                    @security-team
/network/                @network-team
/terraform/modules/vpc/  @network-team @platform-team
/                        @platform-team

The file is read top-to-bottom and the last matching pattern wins. A path can require multiple owners. CODEOWNERS scales review to a team: without it, every PR bottlenecks through the same handful of reviewers; with it, the load distributes.

Bypass actors and what they leave behind

There are three categories of bypass actors:

1. Administrators — admin role can dismiss reviews, push to protected branches, and merge without the required count.
2. Break-glass identities — a separate bot account used for incident response, logged separately from normal admin activity.
3. Repository rules with exceptions — time windows or path-based exemptions.

Every bypass leaves a record — actor, timestamp, PR, and (ideally) a reason field.

Production discipline

1. Two approvals for production changes. One is a rubber stamp; two is a conversation.
2. CODEOWNERS for every changed path. A PR touching /iam/ without the security team is a bug.
3. Author cannot self-approve. The merge button must require an approver other than the author.
4. Stale approvals are dismissed. A re-pushed PR requires a new approval.
5. Bypass actors are configured, not improvised. Break-glass identity with reason field.

Cross-course references

• GitOps with Argo CD - Part VI (Policy): CODEOWNERS-style enforcement at the cluster level.
• CI/CD Pipeline Patterns - Part VIII (ApprovalGates): approval gates in deployment pipelines.
• Terraform for Production Sysadmins - Part XI (PRWorkflows): CODEOWNERS patterns for Terraform modules.

Quiz