Required Reviewers and Status Checks

Required reviewers and status checks are controls used in GitHub and Azure DevOps to prevent code from being merged into an important branch, such as main, until specific review and automated validation requirements are satisfied.

They are commonly configured using:

• GitHub: Branch protection rules / rulesets
• Azure DevOps: Branch policies

1. What Are Required Reviewers?

Required reviewers means a Pull Request must receive approval from a specified number of reviewers—or, depending on platform/configuration, particular people or groups—before it can be merged.

For example:

feature/login
     |
     v
Pull Request
     |
     v
Required Reviewers
     |
     +--> Developer A: Approved
     |
     +--> Developer B: Approved
     |
     v
Eligible to Merge

Why do we need them?

They help ensure that code is not merged solely based on the author's decision.

Reviewers typically check:

• Business logic
• Coding standards
• Security
• Error handling
• Performance
• Tests
• Maintainability

For example, a team may require:

Minimum approvals: 2

If only one reviewer approves:

Reviewer A → Approved
Reviewer B → Pending

Merge → Blocked

Once the required approval conditions are satisfied:

Reviewer A → Approved
Reviewer B → Approved

Merge → Allowed*

* assuming all other required policies/checks also pass.

2. What Are Status Checks?

Status checks are automated validations that must complete successfully before a Pull Request can be merged.

They are usually produced by a CI pipeline or another automated integration.

For example:

Pull Request
     |
     v
CI Pipeline
     |
     +--> Build             ✓
     +--> Unit Tests        ✓
     +--> Code Analysis     ✓
     +--> Security Scan     ✓
     |
     v
Required checks passed

If a required check fails:

Build          ✓
Unit Tests     ✗
Code Analysis  ✓

Merge → Blocked

The developer fixes the problem and pushes another commit:

git add .
git commit -m "Fix failing unit test"
git push

The pipeline runs again.

If all required checks pass:

Build          ✓
Unit Tests     ✓
Code Analysis  ✓

Merge → Allowed*

Again, required reviewer approvals and other policies may still need to be satisfied.

3. Complete Practical Example

Suppose you are working on:

feature/login

and want to merge it into:

main

You push your branch:

git push origin feature/login

Then create a Pull Request:

feature/login
      |
      v
Pull Request
      |
      +--------------------+
      |                    |
      v                    v
Code Review            CI Pipeline
      |                    |
2 approvals required       +--> Build ✓
      |                    +--> Tests ✓
      |                    +--> Analysis ✓
      v                    |
Approved ✓                 v
      |                 Checks ✓
      +---------+----------+
                |
                v
             Merge
                |
                v
              main

If either side fails:

Reviewers approved ✓
Status checks      ✗

Merge → Blocked

Or:

Reviewers approved ✗
Status checks      ✓

Merge → Blocked

Only after all required conditions are satisfied can the PR normally be merged.

4. GitHub Example

In GitHub, protection can be configured for an important branch such as main.

A repository may require:

main
 |
 +--> Pull Request required
 |
 +--> 2 approving reviews required
 |
 +--> Required status checks
 |      |
 |      +--> Build
 |      +--> Unit Tests
 |      +--> Code Analysis
 |
 +--> Merge

For example:

PR #125: Add Login Feature

Review
---------------------
Reviewer 1       ✓
Reviewer 2       ✓

Checks
---------------------
Build            ✓
Unit Tests       ✓
Security Scan    ✓

Merge            → Available

The exact available controls depend on the repository's GitHub rules and plan/configuration.

5. Azure DevOps Example

Azure DevOps provides similar controls through branch policies.

For example, the main branch can have policies such as:

main
 |
 +--> Minimum number of reviewers: 2
 |
 +--> Required reviewers
 |
 +--> Build validation
 |
 +--> Work item linking
 |
 +--> Comment resolution

A typical Azure DevOps PR could therefore require:

Developer creates PR
        |
        v
2 reviewers approve
        |
        v
Build validation succeeds
        |
        v
PR comments resolved
        |
        v
Merge into main

6. Required Reviewers vs Status Checks

They complement each other.

Human Review
     +
Automated Checks
     |
     v
Safer Merge

A successful automated build does not mean human review is unnecessary, and human approval does not guarantee that the application builds or all automated tests pass.

7. Key Points

• Required reviewers enforce human approval before merging.
• Status checks enforce automated validation before merging.
• GitHub provides these controls through repository rules such as branch protection/rulesets.
• Azure DevOps provides similar controls through branch policies.
• Status checks can include:
  • Build
  • Unit tests
  • Integration tests
  • Static code analysis
  • Security scanning
• If a required review or check is incomplete or unsuccessful, the PR is normally blocked from merging, subject to the repository's configured bypass permissions.
• New commits may cause approvals or checks to need to run again depending on repository policy.
• These controls are especially useful for protecting branches such as main, release, and other critical branches.

8. Interview Answer

Required reviewers and status checks are branch protection mechanisms used in GitHub and Azure DevOps. Required reviewers ensure that a Pull Request receives the configured human approvals before merging. Status checks ensure that automated validations, such as builds, unit tests, code analysis, or security scans, complete successfully. If the required approvals or checks are not satisfied, the Pull Request is normally blocked from merging into a protected branch such as main. Together, they improve code quality and help protect important branches.