How to enforce pull request reviewers in GitHub

Kenny DuMez
Kenny DuMez
Graphite software engineer


Note

This guide explains this concept in vanilla Git. For Graphite documentation, see our CLI docs.


Ensuring that the right reviewers are assigned to pull requests (PRs) in GitHub is important for maintaining high standards of code quality and compliance within software development projects. This guide provides a step-by-step approach to enforcing pull request reviewers both through GitHub's built-in Codeowners feature as well as with Graphite Protections.

Enforcing PR reviewers helps to:

  • Ensure code quality: Having the right set of eyes on every code change ensures high quality and adherence to coding standards.
  • Maintain project standards: Specific reviewer requirements can help maintain consistency across the project's codebase.
  • Compliance and accountability: Enforcing reviewer rules ensures that all code changes are vetted by authorized personnel, enhancing security and accountability.

The first step in enforcing PR reviewer rules is to set up Graphite Protections in your repository, offering a more flexible approach compared to traditional GitHub branch protections:

  1. Navigate to your Graphite settings: Access the 'Protections' page within the Graphite web app.

  2. Create a new protection rule: Use the visual editor to define PR merge conditions based on file path, team, or other criteria. This allows you to configure specific review requirements, such as needing approvals from designated code owners without modifying CODEOWNERS files directly.

  3. Specify review requirements: For example, you can require that PRs affecting certain directories have approvals from specific teams or that high-risk changes like database schema modifications require at least two reviewers.

Graphite allows for precise control over who reviews PRs, enabling you to automate and tailor the review process to your team's structure:

  • Team-based reviews: Assign review responsibilities to specific teams or individuals based on the content of the PR. This avoids the limitations of CODEOWNERS by allowing dynamic assignment based on the actual changes made.
  • Conditional approvals: Set conditions under which reviews are required, such as code complexity or impact area, ensuring that the right people review the right parts of a PR.

Graphite Protections automatically enforce your configured review policies, simplifying compliance and ensuring every PR meets your standards before merging:

  • Automate with Graphite: Instead of using GitHub Actions, rely on Graphite's built-in functionalities to enforce review policies. Graphite's engine continuously evaluates PRs against the set rules and updates their mergeability status accordingly.
  • Integration with GitHub: For teams using both platforms, Graphite integrates with GitHub, displaying status checks directly on PRs in GitHub to show compliance with the required review policies.

Regularly review the effectiveness of your PR review policies and make adjustments as needed. This can involve updating protection rules in Graphite, refining team responsibilities, or adjusting the criteria for automated reviews based on ongoing team feedback and development practices.

By leveraging Graphite Protections, teams gain a more adaptable and powerful tool for managing PR reviews, especially useful in dynamic and fast-paced development environments.

To enforce PR reviewer rules you can also set up branch protection policies in your GitHub repository:

  1. Navigate to your repository settings: Go to 'Settings' > 'Branches'.
  2. Add or edit a branch protection rule: Select the branch you want to protect (typically main or master) and click on 'Add rule' or edit an existing one.
  3. Enable required reviews: Check the box for 'Require pull request reviews before merging'. This setting prevents merging until the specified number of approvals from reviewers has been obtained.

To further control the review process, specify who must review PRs:

  • Code owners: Use a CODEOWNERS file in the repository to automatically request reviews from the right people based on the files changed in the PR. This file is placed in the root, docs/, or .github/ directory of the repository and specifies users or teams that are responsible for specific parts of the project.

Example of a CODEOWNERS file:

Terminal
## Format: <path> <owner>
/src/ @frontend-team
/docs/ @documentation-team
  • Number of reviewers: Specify the number of required reviewers to ensure that multiple perspectives are considered before merging changes.

After setting up the required reviewers, enforce these policies consistently across the project:

  • Automate with GitHub Actions: Create custom GitHub Actions workflows that check if the PRs meet the review criteria specified in your branch protection rules and CODEOWNERS file. This can include checks for approvals from specific teams or individuals.

Example of a GitHub Action to enforce reviewer policies:

Terminal
name: Enforce Reviewers
on: pull_request_review
jobs:
check-reviewers:
runs-on: ubuntu-latest
steps:
- name: Check approved reviewers
uses: some-org/review-enforcer-action@v1
with:
required-reviewers: 2
required-teams: frontend-team, backend-team

Regularly monitor the effectiveness of your reviewer policies and make adjustments as needed. This can involve updating the CODEOWNERS file, modifying branch protection settings, or refining your GitHub Actions.

Implementing strict PR reviewer rules is important for maintaining high code quality, ensuring compliance, and fostering accountability within development projects. Whether through Graphite Protections or GitHub's branch protection features, setting up comprehensive reviewer policies ensures that each piece of code is thoroughly vetted by the appropriate experts before integration. Graphite Protections offers enhanced flexibility and control, allowing teams to tailor review processes to fit their specific needs and project dynamics, which is particularly beneficial in fast-paced or complex development environments. By continually monitoring and adapting these review protocols, teams can maintain a high standard of code integrity and project coherence, ultimately leading to more robust and reliable software solutions.

Graphite
Git stacked on GitHub

Stacked pull requests are easier to read, easier to write, and easier to manage.
Teams that stack ship better software, faster.

Or install our CLI.
Product Screenshot 1
Product Screenshot 2