Repository Rules move beyond branch protection

Branch protection has been a GitHub staple for years, but keeping protections consistent across many repositories has typically meant maintaining scripts, cron jobs, and API calls — or relying on third-party tooling. Engineers often don't discover which rules apply until they open a pull request. Repository rules, now generally available, aim to replace that fragmentation with centrally managed, layered rulesets that work across an entire organization.

With repository rules, you can define branch and tag protections in public repositories using a single ruleset that targets multiple branch patterns. Bypass scenarios become more flexible: a GitHub App can be exempted from status checks without needing elevated permissions, and administrators can skip pull request requirements while CodeQL checks still run. Rule enforcement is surfaced across GitHub.com, Git, and the GitHub CLI, and an overview page shows which rules apply to a given branch.

Visibility and policy at scale

For Enterprise Cloud customers, rules can be enforced across all repositories in an organization or a subset of them, which replaces tedious audits with a single place to ensure consistency. Evaluate mode lets you trial a ruleset before committing, and rule insights show the impact of actions like dismissing stale reviews or enabling a linear merge history — no more guessing in production.

Index page of Organization Rulesets. Showing two active rulesets, one in evaluate and one disabled

Metadata rules extend governance beyond branch protections. You can standardize branch names, commit messages, and author email addresses to meet organizational standards — for example, enforcing SemVer on protected tags and Emoji-Log formatting on commit messages.

Compliance and security controls are fundamental to keeping applications safe. At Thomson Reuters, it's important we properly enforce these policies. With repository rules, GitHub gives us the confidence to know we are enforcing our policies across an organization effectively, keeping our applications safe for end customers.
- Darren Trzynka. Senior Cloud Architect // Thomson Reuters

Practical rulesets for common scenarios

Production repositories typically need a few core controls: peer-reviewed pull requests, CI/CD gatekeeping for tests and releases, and lightly restricted topic branch namespaces. The goal is to add only the rules needed to meet security and quality objectives, since each additional rule introduces friction for contributors.


POST /repos/{owner}/{repo}/rulesets

{
    "name": "team rules-ex-1",
    "target": "branch",
    "enforcement": "active",
    "conditions": {
        "ref_name": {
            "include": [
                "~DEFAULT_BRANCH",
                "refs/heads/feature-*"
            ],
            "exclude": [
                "refs/heads/dev-*"
            ]
        }
    },
   "rules": [
        {
            "type": "pull_request",
            "parameters": {
                "require_code_owner_review": false,
                "require_last_push_approval": true,
                "dismiss_stale_reviews_on_push": false,
                "required_approving_review_count": 2,
                "required_review_thread_resolution": false

            }
        },
        {
            "type": "required_status_checks",
            "parameters": {
                "required_status_checks": [
                    {
                        "context": {status check context name}",
                        "integration_id":{integration ID that this status check must originate from.}
                    }
                ],
                "strict_required_status_checks_policy": false
            }
        },
        {
            "type": "deletion"
        },
        {
            "type": "non_fast_forward"
        }
    ]
}

Organization-wide governance

When enforcing standards across an organization — like requiring two reviewers on every pull request to meet compliance needs — you need a plan for exceptions. One approach is to place a designated team on the bypass list for organizational rulesets so someone can respond in "break-glass" situations. Another is to model potential exceptions in evaluate mode first and then review those events in ruleset insights before making anything permanent.


POST /orgs/{org}/rulesets

{
    "name": "👀 + 👀",
    "target": "branch",
    "source_type": "Organization",
    "enforcement": "active",
    "bypass_actors": [
        {
            "actor_id": 1,
            "actor_type": "OrganizationAdmin",
            "bypass_mode": "pull_request"
        }
    ],
    "conditions": {
        "repository_name": {
            "exclude": [],
            "include": [
                "~ALL"
            ]
        },
        "ref_name": {
            "exclude": [],
            "include": [
                "~DEFAULT_BRANCH"
            ]
        }
    },
    "rules": [
        {
            "type": "deletion"
        },
        {
            "type": "non_fast_forward"
        },
        {
            "type": "pull_request",
            "parameters": {
                "require_code_owner_review": false,
                "require_last_push_approval": false,
                "dismiss_stale_reviews_on_push": false,
                "required_approving_review_count": 2,
                "required_review_thread_resolution": false
            }
        }
    ]
}

Layered rulesets for bots without overreach

GitHub Apps often don't need admin access to commit, but under the old branch protection model, that was the only way to let them skip status checks. Repository rules support layering multiple rulesets, which allows for a narrow bypass in one ruleset combined with a second ruleset that has no bypass list at all.

  • "For all" ruleset: no bypass list; targets the default branch; restricts deletions, blocks force pushes, and requires a pull request before merging.
  • "Bots and Friends" ruleset: bypass list contains the bot; targets the default branch; requires status checks and "branches to be up to date before merging."

Result: the bot can skip checks but still can't delete branches or force push. For more details, the ruleset documentation and community discussions cover additional patterns.