Setting rules and policies for GitHub pull requests

Sara Verdi
Sara Verdi
Graphite software engineer


Note

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


Pull requests (PRs) are the primary means through which changes are reviewed and integrated into larger codebases on GitHub. This guide explores how to establish robust PR rules and policies on GitHub, and how Graphite Protections can enhance these settings to support a fast-paced development environment, especially in monorepos.

The establishment of pull request policies helps maintain code quality and ensures that changes meet organizational standards before merging. Here are the steps to set up basic GitHub PR rules with branch protection rules

  1. Navigate to your repository settings on GitHub and select "Branches" in the sidebar.

screenshot of branch settings

  1. Branch protection rules: Click on "Add rule" to define policies for your target branch (commonly main). Here you can:
    • Require pull requests before merging, ensuring all changes are reviewed.
    • Require status checks to pass before merging, such as continuous integration (CI) builds.
    • Enforce a minimum number of reviewer approvals.
    • Restrict who can push to the protected branch, often reserved for maintainers or automated systems like CI.

screenshot of adding a rule

  1. CODEOWNERS file: Create a CODEOWNERS file at the root of your repository to automatically assign reviewers to PRs based on the files changed. This ensures that the right subject matter experts review relevant changes.

Suppose you want to enforce a rule where all changes to the main branch require at least two approvals and passing CI tests. Your branch protection rule settings might look like this:

  • Require a pull request before merging.
  • Require status checks to pass before merging.
  • Require at least 2 approvals.

Graphite Protections offer a more granular level of control over PR mergeability, extending the capabilities of GitHub's branch protection. These are especially useful in complex project structures, such as monorepos, where different sections of the codebase may have different security, reliability, or compliance requirements.

  1. Install the Graphite GitHub app on your organization's GitHub account to enable integration.
  2. Configure Protections: Go to the Protections page in your Graphite dashboard. You can set rules such as:
    • Required CI checks specific to file paths or directories.
    • Number of required approvals, potentially higher for sensitive parts of the codebase.
    • File path-based approvals where only designated team members can approve changes to specific parts of the repository.

screenshot of Graphite Protections

For instance, you might configure Graphite Protections to:

  • Require at least 2 reviewers for high-risk changes, such as modifications to database schemas or key configuration files.
  • Allow teams autonomy by enabling them to approve changes to their code sections without altering global CODEOWNERS settings.
  • Mandate that only the security team can approve security-related configuration changes.

These rules ensure that PRs in your GitHub repository can only be merged once they meet all defined conditions, visibly indicated on the PR page in GitHub and Graphite. This seamless integration between GitHub and Graphite allows for a dual-layer of protection, making your codebase both flexible and secure.

By combining GitHub's built-in PR rules with the advanced features offered by Graphite Protections, organizations can create a tailored, secure, and efficient code review process. This not only simplifies the management of complex projects but also ensures that each code change is rigorously evaluated, maintaining high standards of code quality and security.

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