Approval

What Is an Approval?

An approval is a formal signal from a code reviewer that they have examined the changes in a pull request and consider them ready to merge into the target branch. On platforms like GitHub, GitLab, and Azure DevOps, approvals are a first-class feature of the review workflow: reviewers explicitly choose to “Approve” a pull request, and branch protection rules can require one or more approvals before the merge button becomes available.

Approvals serve as the quality gate between proposed code and production. When a reviewer approves a pull request, they are affirming that the code meets the team’s standards for correctness, security, readability, and maintainability. In most organizations, this is not a rubber stamp — it carries professional accountability. If a bug reaches production, the reviewer who approved the change shares responsibility alongside the author.

The number of required approvals varies by team and by the criticality of the code being changed. A startup might require a single approval from any team member. A large enterprise might require two approvals, including one from a designated code owner for the affected files. Highly regulated industries like finance and healthcare often mandate approvals from specific roles (security lead, compliance officer) for changes that touch sensitive systems.

How It Works

On GitHub, the approval workflow is tightly integrated with branch protection rules. Here is a typical configuration:

# Branch protection settings for main branch
required_pull_request_reviews:
  required_approving_review_count: 2
  dismiss_stale_reviews: true
  require_code_owner_reviews: true
  require_last_push_approval: true

This configuration enforces several constraints:

• Two approving reviews are required before the PR can merge.
• Stale reviews are dismissed when the author pushes new commits, requiring re-review.
• Code owner approval is mandatory. If the CODEOWNERS file designates @backend-team as owners of src/api/, any PR touching those files needs an approval from someone on that team.
• The last push must be approved. This prevents the author from adding unreviewed changes after receiving approvals.

A CODEOWNERS file maps file patterns to responsible teams or individuals:

# CODEOWNERS
src/api/           @backend-team
src/auth/          @security-team
*.sql              @database-team
infrastructure/    @platform-team

When a pull request modifies files matching these patterns, GitHub automatically requests reviews from the designated owners and requires their approval before merge.

On GitLab, the equivalent feature is called “Merge Request Approvals,” and it supports approval rules with similar semantics. Azure DevOps uses “Required Reviewers” policies that achieve the same outcome.

Why It Matters

Approvals are the mechanism through which teams enforce code quality at scale. Without them, there is nothing preventing unreviewed code from reaching production. Their impact extends across several dimensions:

• Defect prevention. Research from SmartBear’s study of 2,500 code reviews found that having at least one reviewer catch issues reduces production defect density by 60-80%. The approval requirement ensures that every change gets at least one set of human eyes.
• Knowledge distribution. The approval process forces at least one other person to read and understand every change. Over time, this prevents knowledge silos where only one person understands a critical system.
• Compliance and auditability. In regulated industries, approval records provide an audit trail showing who reviewed and authorized every change. Standards like SOC 2 and ISO 27001 explicitly require documented evidence of peer review for code changes.
• Team accountability. When approvals are required and tied to specific individuals, the review process becomes meaningful rather than ceremonial. Reviewers invest more effort when their name is attached to the approval.

Best Practices

1. Require at least one approval for all production code. This is the minimum viable quality gate. Even small teams benefit from a second pair of eyes. Configure branch protection rules to enforce this automatically rather than relying on social conventions.
2. Enable “dismiss stale reviews” to prevent unreviewed code from slipping through. Without this setting, an author can receive approval, then push additional commits (potentially introducing new bugs), and merge without the new code being reviewed.
3. Use CODEOWNERS to route reviews to domain experts. Generic review assignments often lead to rubber-stamping because the reviewer lacks context. Code owners have the domain knowledge to provide meaningful feedback.
4. Set a target turnaround time for approvals. Google’s internal data shows that teams with a 24-hour review SLA ship faster than teams without one. A pending PR is idle inventory — it accumulates merge conflicts, blocks dependent work, and costs context-switching when the author returns to it days later.
5. Combine human approval with automated checks. Require both a passing CI pipeline and human approval before merge. Automated tools catch mechanical issues (test failures, lint violations, security scanning), freeing human reviewers to focus on logic, design, and architecture.

Common Mistakes

1. Rubber-stamping approvals. Approving a PR without reading the code undermines the entire review process. If a team notices that approvals happen within seconds of PR creation, it is a sign that the process has become ceremonial. Address this by tracking review depth metrics and fostering a culture where thorough review is valued and rewarded.
2. Requiring too many approvals. Requiring three or four approvals for routine changes creates bottlenecks that slow development without proportionally increasing quality. Research from the DORA team shows that lightweight, fast review processes correlate with better software delivery performance. Reserve multi-approval requirements for high-risk changes (security-critical code, database migrations, infrastructure).
3. Not dismissing stale reviews after force-pushes. When an author force-pushes or rebases after receiving approval, the approved code may be substantially different from what the reviewer saw. Always enable stale review dismissal to ensure that the final merged code has actually been reviewed.