Skip to main content
In this guide we’ll configure GitHub repository rulesets at the enterprise, organization, and repository levels and demonstrate how they interact. You’ll learn how to:
  • Create branch rulesets and choose enforcement modes.
  • Target specific organizations and repositories.
  • Combine rules across layers and understand precedence.
  • Use bypasses for emergency exceptions.
Rulesets can be created for branches, tags, or pushes and set to one of three enforcement modes: Active (enforced), Evaluate (trial mode), or Disabled. Use Evaluate to test without blocking workflows.

​
1) Create an enterprise-level branch ruleset

Start inside the enterprise account (Next Gen Gaming). Create a new branch ruleset to centrally protect important branches across many repositories.
  • Name: “Enterprise Clean Protection”
  • Type: Branch ruleset
  • Enforcement: Active
  • Bypass: leave empty for now (we’ll configure bypasses later)
A dark-themed GitHub Enterprise settings screen for "Repository rulesets / New branch ruleset" showing a form to name and protect branches. The left sidebar lists Policies and repository options, and an Enforcement status dropdown (Active / Evaluate / Disabled) is open.
Next, choose the scope for the ruleset: target organizations and repositories to limit which repositories the rule applies to. In this example we apply the ruleset to all organizations within the enterprise, but filter to only private repositories so the rule only affects the intended set.
A dark‑theme screenshot of a GitHub Enterprise settings page showing a code ruleset configuration (bypass list, target organizations, repository and branch targeting criteria). The left sidebar shows navigation items like Projects, Advanced Security, and Personal access tokens.
For branch targeting include only the main branch (you can use include/exclude patterns for feature branches). Remove default rules if needed and add a single rule:
  • Require a pull request before merging
  • Require at least 1 approving review
Click Create to save the enterprise-level ruleset.

​
2) Verify enforcement in a repository

Open the target repository (App Backend). Under Settings → Rulesets you will see the enterprise-managed ruleset listed and enforced. Enterprise-managed rulesets cannot be edited at the repository level — developers will see the enterprise rules applied when they attempt to modify protected branches. If you attempt to edit the README and commit directly to main, the UI will block the direct commit and prompt you to create a branch and open a pull request. Example local/inline change:
Creating the pull request will report that at least one approving reviewer is required (coming from the enterprise ruleset).

​
3) Add an organization-level ruleset

Next, create a ruleset at the organization level (game-devstudio). This lets you enforce additional requirements for all the organization’s repositories.
  • Name: “organization port scanning ruleset”
  • Type: Branch ruleset
  • Enforcement: Active
  • Target: All repositories in the organization
A dark-mode screenshot of the GitHub organization "game-devstudio" Settings page showing the Repository rulesets area with an enterprise ruleset listed and a green "New ruleset" dropdown open offering New branch/tag/push ruleset and Import options. The left sidebar shows other organization settings like Policies, Billing, and Repository.
Choose the branch pattern (again, include only main for this demo).
A dark-mode screenshot of a GitHub organization repository settings page with a "Filter" modal open showing repository filter options like Visibility, Fork, Deployable, Deployed, Language, and Exclude. The left sidebar lists settings sections such as Rulesets, Codespaces, Actions, and Webhooks.
At the organization level, add a rule to require code scanning results. GitHub Code Scanning with CodeQL is available by default; you can require results from CodeQL or another configured scanning tool and select minimum severity (e.g., High/Critical) that should block merging. For this example, require CodeQL scanning results.
A dark-themed screenshot of a GitHub organization settings page for repository rules showing required tools (CodeQL) and options like requiring code quality results, code coverage, Copilot code review, license compliance, and various restrictions. The page also shows a "Create" button at the bottom.

​
4) Add a repository-level ruleset

In the App Backend repository create a branch ruleset named “Repository Multi-PR Approval”:
  • Type: Branch ruleset
  • Enforcement: Active
  • Branch: main
  • Rule: Require 2 approving reviewers for pull requests
Because this repository now matches three rulesets (enterprise, organization, repository), GitHub enforces the strictest combination of applicable rules. In practice:
  • The repository’s requirement for 2 approvals overrides the enterprise requirement for 1 approval (the stricter value wins).
  • The organization rule still requires successful CodeQL scan results.
When editing the README and opening a PR, the workflow will create a branch and the PR will require two approvals. Example diff shown in the PR:
At this point the PR is blocked for two reasons:
  • The repository-level rule requires two approving reviews (stricter than the enterprise-level one).
  • The organization-level rule requires a successful CodeQL scan result on the relevant branch; if no scan results exist GitHub indicates merging is blocked for missing required scan results.

​
5) Configure bypasses (use sparingly)

If you need emergency exceptions, add bypass entries at the enterprise, organization, or repository levels. Bypasses can be scoped to roles (e.g., enterprise owners, organization admins, repository admins) and limited to specific rule types (for example, allow bypass only for pull request rules). Bypasses override protections, so apply them sparingly.
A dark-themed GitHub Enterprise "Policies" settings page showing a repository ruleset named "enterprise-main-protection" with enforcement marked Active. A floating "Add bypass" panel is open listing actors (Enterprise owners, Copilot, Dependabot, etc.) that can be exempted from the ruleset.
In this demo, organization and repository admin roles were added to bypass lists at each layer. After those bypasses are saved, a bypass-eligible actor can merge the pull request without waiting for approvals or code scanning results.
Ruleset precedence: when multiple rulesets apply, GitHub enforces the strictest combination of rules. Bypasses are a powerful override and should be used only when necessary.

​
Quick reference: ruleset levels and typical use

This workflow demonstrates how to create rulesets at multiple levels, verify enforcement in a repository, and use bypasses for controlled exceptions.

Watch Video