Repository Rules GA Feedback

[patrick-knight]

Hey, Y'all!
I’m excited to announce that Repository Rules are now Generally Available! 🎉

❓ What does this mean?
Repository Rules are an evolution of our branch and tag protections, designed to scale more efficiently. These rules make it easier to protect branches and tags in your repositories and allow everyone collaborating on a repository to understand the rules more readily.

For GitHub Enterprise Cloud customers, you can enforce these rules across your entire organization, ensuring consistency and security. Plus, there's an evaluation mode that lets you try these rules in a 'dry run', helping you understand the impact of new rules before they become active.

📑 Want to learn more? Here are some resources:

• Our blog post provides an overview of the new feature and its benefits.
• The docs give you all of the details about how repository rules work.
• 🎥 Youtube video talking a bit about repository rules

❔ Still have queries?

• Feel free to post here for feedback.
• Previous insights shared on the beta discussions is still top of mind for us as we continue to iterate on rules.
• For bugs or deeper questions please reach out to support.

💯 A massive thank you to everyone in the community, the feedback and engagement has been invaluable.

🐛 Known issues:
Some of the more common or noteworthy issues we are tracking:

• Organization rules do not currently support “Require deployments to succeed before merging”
• Only Organization owners can create and manage organization rulesets. There are now org customer roles which include a role for rulesets.
• No merge queue support at the moment Now GA!

[kevinlul]

For the use case of exempting bots, how do I exempt commits using the default GitHub Actions token from a workflow?

[vibro]

@patrick-knight I am using a Github App token to do the push action, but it's still showing up in the Repo Rules audit log as Github Actions[bot]. See discussion here where I opened a ticket with the push action, but I think it may be a Rules issue.

[patrick-knight]

Hey @vibro,

Two things, are the insights correct when using "normal" git commands. And can you also opt to try this update to your workflow:

- name: Push changes
        uses: ad-m/github-push-action@v0.6.0
        with:
          github_token: ${{ steps.generate_token.outputs.token }}
          branch: ${{ env.BRANCH }}

[NushaMBZ]

ok

[samsonmobisa]

Noted

[Jack5237]

ok

[fproulx-boostsecurity]

Looks like when comparing to Branch Protection, it is currently missing the Require review from Code Owners feature.
It's also, not clear if Require approval of the most recent reviewable push is actually covered by default or it's also missing that feature.

[patrick-knight]

Hey @fproulx-boostsecurity,

Those options are available when you select "Require a pull request before merging".

[bobby-lin]

Is it possible to have access control rules for each repo? For example, each repo should not have more than 10 users with admin permission

[patrick-knight]

This experience is focused on branch and tag protections.

[Jack5237]

ok

[jankudev]

What happened to the standard "branch protection" that was available in the menu previously and the related API (aka does the branch protection API work the same or creates a rule in the background - /repos/(owner)/(repo)/branches/(branch)/protection ).

This seems to be the feature for newly created repositories and it creates some UI inconsistencies people get confused about.

Will any migration from the "branch protection" settings into a "branch protection rule" happen or is it up to the repo owners to manage the transition by themselves?

We're using the enterprise cloud subscription and have automation in scripts that seems is broken so we're doing a root cause investigation and noticed the Changelog + Blog Post and missing UI settings, but no detailed info anywhere.

Anyone having the same issue?

[patrick-knight]

@jankudev The new repository rules work along side the existing branch protections, so no existing functionality has been removed.

Will any migration from the "branch protection" settings into a "branch protection rule" happen or is it up to the repo owners to manage the transition by themselves?

Currently the transition will be manual as there is a not a full 1:1 migration path and but we are exploring opportunities to assist with the migration in the future.

It is possible that branch protections we're disabled via "the danger zone" and can be reenabled there as well:

[carlosjgp]

I've found a use case where the PR checks are not working

I get 422 error

{
	"3": {
		"_dirty": true,
		"_enabled": true,
		"_id": -43,
		"parameters": {
			"required_status_checks": null,
			"strict_required_status_checks_policy": true
		},
		"ruleType": "required_status_checks"
	}
}

[patrick-knight]

Once you finish selecting the checks hit the ➕ sign to finalize and save the ruleset.

[LyleDavis]

Would it be possible to introduce rules around how PRs are merged via these rulesets?

For example, using a ruleset to enforce across multiple repositories that PRs must be merged via a squash and merge strategy. As far as I can tell this setting is still only available at the repository level which means we have to configure it in all relevant repos individually rather than applying it on a ruleset that applies to a specific list of repos.

It is currently possible to restrict to either rebase merge or squash merge via requiring linear history, but for repos defining infrastructure as code we prefer squash and merge and to disable rebase merge so that commit messages all refer back to their relevant pull request when commit messages are sent to audit logs of deployments elsewhere.

Other than that the new feature is amazing, I was worried I’d have to start diving into managing repos via terraform which is a layer of complexity I’m happy to avoid. This in combination with template repos is very powerful.

[patrick-knight]

Would it be possible to introduce rules around how PRs are merged via these rulesets?

This is on our shortlist backlog of enhancement we want to make to rulesets, no commitments I can share on timelines but it is been a topic of conversation.

[MichaelJJ]

Question on rule behavior, I created a rule that has "Repository admin" in the bypass list and the option "Restrict updates" enabled. Pull Requests are blocked, even though I am a repository admin, is this expected?

Is this supposed to be the same as the branch protection rule "Restrict who can push to matching branches"?

[jaimebarriga]

Any updates on this? It's 2025 and this still seems to be an issue. I have a repo of which I am an admin. I created one ruleset that has two rules:

• Restrict updates
  • Added org admins, repo admins, write role, maintain role to the "Bypass list"
    
• Require status checks to pass

When I create a PR against the branch that has the rule, I get

I don't want to check the bypass rules checkbox as that would also bypass the status checks

[jonenst]

hi @patrick-knight , are there any plans about this ? For people who consider the bypass UI unacceptable (because it trains users to bypass, and it's not easy to see what exactly you are bypassing), my understanding is that the closest alternative would be to make the people who are allowed to merge codeowners and require approval from a codeowner, but it requires more setup, it doesn't give you as much control on the exact moment when a PR is merged, and prevents using codeowners for any other purpose.

[trask]

🙏🙏🙏 we are unable to migrate to rulesets in the https://github.com/open-telemetry org because of this

[HughGrovesArup]

+1 for this being confusing when migrating

[trask]

the recent https://github.blog/changelog/2025-11-03-required-review-by-specific-teams-now-available-in-rulesets/ may be helpful here in some cases

[mohitnvs2397]

Repository rule violations found * Cannot create ref due to create name restrictions. * Branch name must start with a matching pattern: ^feature/\d+-(.*)$. Actually (this what is popping when i try to create branch with matching pattern also). Iam setting rulesets in GitHub, even after setting up branch naming convention regex pattern in metadeta restriction. how should give branch name to create the given regex pattern. help me create branch name patterns, what should i give it and what and all i should enable in rulesets to work the pattern creation. You can have a look at the screenshot below. Kindly do help me out with this.

[patrick-knight]

Hi @mohitnvs2397,

The rules selected are behaving as defined. As selecting restrict creations blocks the creations of new branches. As far as the rule around branch naming patterns, there seem to be different configurations in the screenshot vs the text post so it's hard to say there. Is the goal to ensure all branches start with feature/

[0xCVH]

I'm looking to enforce approvals for PRs. 1 approval org-wide. However, we have repositories that have already configured 2 approvals. Will it be overwritten? Will we still be able to configure higher approvals for specific branches?

[patrick-knight]

Rule from the org layer on-top of existing rulesets or branch protections. Effectively you get the most restrictive outcome. If at the org you only define 1 PR approval but at some reposts that is two or three, the repository levels wins. However, the repo would be allowed to have less than 1 approval since that is the org defined minimum. Hope that helps.

[patimen]

Can we get the opposite of an exemption list, like an application list? For instance, I want some checks to apply ONLY to certain groups of people...

[patrick-knight]

We're not planning on that, but I am curious to learn more about this scenario when checks are required for only a small group.

[patimen]

Our immediate scenario is that some outside contributors (internal to our company) just aren't up for the rigor of, say, resolving all conversations or abiding by strict static analysis. But our core contributors would still like those requirements, and we can manage outsiders by reviews instead.
I could see it also in the reverse, where outside contributors are held to a higher standard, or specific people (say, people new to a project) need, say 2 approvals instead of just one for core contributors.

[iainlane]

We just tried to enable Require linear history on our monorepo (some of our CI checks don't play very nicely with merge commits and developers get in a mess with it - we are using squash merging at actual merge time), but we had to revert the setting because there are some merge commits far back in the history before we changed the settings and any merge commit in the branch being pushed causes the rule to deny the push. So nobody could push anything.

Is there a way for us to have this setting, but only for commits not in the main branch? Or some other similar requirement. If not, would you consider it for the roadmap in a future iteration?

[shyvum]

@patrick-knight can you look at this? we are also facing the same.

[shyvum]

bump @patrick-knight

[patrick-knight]

Hey y'all thanks for sharing feedback here. This post has gotten pretty big so on occasions I miss some replies and threads 😬

At the moment we don't have any plans for supporting this outside of bypassing the rule.

[adambiggs]

Seems like this rule is kind of broken currently... The first time anyone bypasses the rule, it seems that every other commit after that also needs to be bypassed.

We're migrating all our repos to a monorepo, and we want to enforce linear history for regular day-to-day work. But would like to create a merge commit using --allow-unrelated-histories for the initial commit when an external repo's history is merged into the monorepo.

I assumed the rule was only enforced for newly added commits, not the entire branch history going back to the beginning of time.

[OneCyrus]

What is the state of the merge queue support? Is this something on the near term roadmap or a technical challenge which will require quite some time to implement?

[patrick-knight]

The upcoming release will allow you to create a merge queue configuration inside rulesets inclusive of bypass.

Today you'd need to a repo admin or have the custom role to bypass rules to skip the merge queue defined in the old branch protection rules.

We're wrapping up a few last minute changes and should be out in a public beta pretty soon here.

Sneak peek:

[shyvum]

looks good, by when would we be able to see this on enterprise cloud?

[shyvum]

@patrick-knight any update here?

[patrick-knight]

We're aiming for mid-next week. There were a few things to wrap up on rule insights for queued PRs that took a bit longer than planned.

[patrick-knight]

This is now in public beta!
https://github.blog/changelog/2024-02-27-repository-rules-configure-merge-queue-rule-public-beta

[kaankoken]

I am not able to add status check on rulesets.
The error is "Invalid rules: 'Required status checks'"
I tried both of my private & public repositories, and I could not add status-check

Edit: I checked via the developer option, and it gives a 422 status code. Also, sudo is true

[kaankoken]

@patrick-knight Okay thanks, but it is super confusing. I think should be parallel what we used to use in branches.

[patrick-knight]

Thanks for the feedback we're planing future enhancements here to make that clearer.

[lsantosthoughtworks]

Hi @kaankoken How did you manage to type and select a rule (status check) on the "Required status check to pass before merging" field ?
I'm trying to make it from the organization settings when typing but nothing comes up at all.

Would you have any direction based on your experience ?

[patrick-knight]

@lsantosthoughtworks Org checks will only display apps that are installed at the organization level. These apps must be installed with the checks:write and statuses:write permissions. As far as the check names themselves we do not catalog them at the org level, but all you to type in the name of the check you require.

[patrick-knight]

Following up to share this ➕ has been removed and a new interface is rolling out.

[kaankoken]

Can someone help me with to bypass branch projection rules? I have already checked a post but did not worked out.

Edit: I am trying to apply for my personal pro account

What I done is:

• I removed all branches rules from branches.
• I have created a rule for my beta branch from Rulesets and applied following

1. Enforcement status: Active
2. Bypass list: App that I created for creating automated PR's
3. Target Branches: beta
4. Branch protections: Restrict creations, Restrict deletions, Require linear history, Require a pull request before merging, Require status checks to pass before merging, Require branches to be up to date before merging & 5 status check, Block force pushes

Still I could not bypass it

[patrick-knight]

😬 Sorry I missed replying here. If you use a team/role does the bypass work as expected? If so it might be additional configuration/permissions on the app.

[unicornware]

are there any plans to make org-wide rulesets available with a github team plan? i'm the only member of my organization. i don't want to be forced into an enterprise plan, especially with required workflows moving to repository rules.

[patrick-knight]

Not at the moment. We are investigating bringing an actions workflow rule to repo rulesets.

[unicornware]

would that allow team plan users to define org-wide required workflows?

[patrick-knight]

That would allow for requiring workflows per repo.

[rajbos]

Feedback on "Require status checks to pass": searching for a check is hard. If I want to know what options are available, I have to start typing before I get information. And that you have to type is not even clear from the UI. I was breaking my head for ten minutes trying to figure out why my test was not visible (was it to old to show up, did I misconfigure something). This should a) be better to understand and b) just fill the list when I click on the dropdown!

[hestonhoffman]

HI! This is a great feature, but I'm wondering if it would be possible to show the user the rule description in addition to, or instead of, the regex rule?

Regex can be pretty difficult to decipher and it would be helpful to be able to tell our contributors what we're expecting in plain language. For example, if I want to enforce a slash in their branch name with something like .*?\/.*, I'd prefer to be able to use the rule description in the error message "Branch name must follow the convention: <username>/<branch_name>".

[sduquette-devolutions]

I came here to request exactly the same thing, being able to provide an error message would be a must. The regex patterns are not easy to decipher and it becomes especially confusing for users if we set multiple rules that use regexes.

[Sylfwood]

@patrick-knight I second this proposal. In fact, this issue is what prevents us from fully switching our validation processes to rulesets. Our regex patterns can be complex, and a developer might have no clue what is being required.

It would be better if we could define a custom error message for regex rulesets (e.g., branch name, commit message, etc.).

For this rule, a custom message like "Commit message must follow this format: [<ticket>] commit message" would be useful.

[willsawyerrrr]

When a repository ruleset prevents a pull request from being merged and auto-merge is enabled on the pull request, disabling the ruleset does not trigger the auto-merge of the the pull request, despite there no longer being a blocking restriction.

Are there intentions for auto-merge to be triggered by repository rules, or will it only respect branch protection rules?

[SAHASRABDI]

Hi Team,
I am trying to implement a validation function by fetching the active rulesets associated with a branch using the API: GET
/repos/{owner}/{repo}/rules/branches/{branch}.This API just list only the Rules info( as intended I believe) but facing a limitation of not having a direct API to fetch the BYPASS ACTORS information.

Workaround I tried

• Try to fetch all the Org level + Repo level rulesets and then filter out those actively enforced on my required target branch and then query the bypass actor list (Problem: with immense number of rulesets from both levels seems inefficient)
• Use the response from GET /repos/{owner}/{repo}/rules/branches/{branch}
  Get the RulesetID and then fetch the ruleset info using API: GET /repos/{owner}/{repo}/rulesets/{ruleset_id} and this response has bypass actor info (Problem: If a ruleset applies to a branch, has no rules, but has an empty bypass_actors list (i.e., no one can bypass protections), it still enforces protection — but it is not returned by /rules/branches/{branch})

Request:

• Include the Bypass actor information in the metadata in /rules/branches/{branch} alongside the Rules info
• Or a separate API to directly fetch the Bypass actor information for a branch in a repo
• Any guidance to handle this use case in an optimised manner is highly appreciated

Thanks!

[electrofelix]

Is it possible to require status checks to pass only when certain files have been modified?

Dependabot will post a check run when .github/dependabot.yml is updated, some backstage SaaS's will watch for changes to catalog-info.yaml, while one would hope errors are not missed, it would be nicer to simply block them from merging. Similarly with internal github apps managing some configs it would be desireable to only check when they are modified and also report if valid, but to enable a status check require means they must always run and just report success when the file of interest is not being updated.

For fully internal apps, it's possible to adjust but not really an option for external provided checks.

[simon-abbott]

Is there any way to require a review from a specific team without using CODEOWNERS? We want to require that certain contributors (e.g. external contractors or new hires) require a review from a more senior developer before their changes can be merged. However, we don't want to use a CODEOWNERS setup as (as far as we can tell) that would result in all of us being assigned as a reviewer on every PR, including ones made by automated tools (such as Dependabot or Renovate).

It would be awesome if there was a setting for "Require approval from", where you could select any team(s) / apps / etc. that you require, without needing to go through a CODEOWNERS file. That way we could require that there is an approval from a specified team without auto-assigning them to every PR. Plus it would make it easier to have different approval requirements for different branches (i.e. Team A needs to approve merge into QA, but Team B needs to approve a merge into production) without needing to somehow keep CODEOWNERS from merging between branches as well.

Alternately, if there's some setting I don't know about to only auto-request CODEOWNERS review on certain target branches, that would also be perfect. Yes I know the CODEOWNERS file is read per-branch, but we use a branching workflow and try to keep all of them as in-sync as possible, so there's no good way for us to keep different CODEOWNERS on different branches.

---

To hopefully head-off certain follow-up questions:

• Q: Why not just use CODEOWNERS?
  • A: We don't want the entire "approvers" team to be auto-mentioned and subscribed to every PR
• Q: Why not "Enable auto assignment"?
  • A: Because not every member of the "approvers" team is a regular reviewer, and we don't want to round-robin assign to someone who is only in GH part-time
• Q: Why not remove those part-time approvers from the list and add them to a Bypass team instead? That way they could still merge PRs, but they wouldn't be assigned
  • A: Because then we still have the issue of automated PRs (i.e. Dependabot / Renovate / etc.) cluttering up our inboxes / review request lists, even though they are targeting a branch that doesn't have branch protection rules!

[EngrAeeGrabb]

please i need to confirm if branch protection rules are still available for free on personal accounts

[Tamilvendhan23]

Repository Rules sound like a real game-changer, especially for teams managing multiple collaborators and repos. The ability to enforce consistent policies across branches and tags is going to make things way more streamlined, especially for larger organizations where governance and compliance matter.

Personally, I love the evaluation mode idea — being able to dry-run a rule before enforcing it gives teams a safe space to experiment and refine without disrupting active workflows. That’s such a thoughtful feature.

Looking forward to exploring this more. Also, appreciate that known issues were clearly mentioned — transparency like this really helps teams plan better. Curious to see when merge queue support will be added. 🙌

Thanks again for shipping this — can’t wait to dive in!

[Forbrowsing]

Absolutely agree with you! The evaluation mode really stood out to me too

[chorman0773]

I'd be interested in seeing the ability to add a rule for PR approvals that requires a minimum period of time between the approval (without an intervening rejection) and being merged, similarily to "Final Comment Periods" used by the Rust project. Having this builtin would be nice rather than having to track the timer out of band.

[thewisenerd]

does an "org admin" role inherently assume a "repo admin" role? (in the context of repos, yes; but also in the context of rulesets?)

i've created a ruleset with bypass for "repo admin" role, but am able to see the "bypass rules" checkbox on a repo, as an "org admin". i am NOT a "repo admin" on the repo targeted by the ruleset.

[Meierschlumpf]

Would be nice to have an option to only enforce rules for certain source-branches (like for example branches from renovate). So I would require the renovate/stability-days status check only for those prs but not for any other. Right now we configured it to require it always and just skip the check by clicking on the checkbox:

[thewisenerd]

all the api endpoints needing '"Administration" organization permissions (write)' is a little weird.

i'd suggest downgrading a few of these permissions to "(read)" for safety reasons. the current options i have are

a. either, creating a separate standalone fine-grained token and mgmt;
b. or, elevate my current fine-grained token which already has appropriate (read) to (write).

https://docs.github.com/en/rest/orgs/rules?apiVersion=2022-11-28

• Get all organization repository rulesets - "Administration" organization permissions (read)
• Create an organization repository ruleset - "Administration" organization permissions (write)
• Get an organization repository ruleset - "Administration" organization permissions (read)
• Update an organization repository ruleset - "Administration" organization permissions (write)
• Delete an organization repository ruleset - "Administration" organization permissions (write)
• Get organization ruleset history - "Administration" organization permissions (read)
• Get organization ruleset version - "Administration" organization permissions (read)

https://docs.github.com/en/rest/repos/rule-suites?apiVersion=2022-11-28

• List repository rule suites - "Administration" organization permissions (read)
• Get a repository rule suite - "Administration" organization permissions (read)

[thewisenerd]

the "Get a repository rule suite" does not work for org rule suites

when using the ID from "Get all organization repository rulesets", the endpoint fails with a 500, and message "Client error '404 Not Found' for url 'GET https://api.github.com/orgs/{{ORG}}/rulesets/rule-suites/{{ID}}'"

[nathan-summers-landg]

Require multiple approval before deploying to an environment.

We have been using the 'environment requires approval' feature, but our corporate policy mandates 3 approvals before deploying to our production environment.

I cant find any option to require more than 1 approval.
GH has most of the approval feature in place - it seems a bit of an oversight to not allow multiple.

What are the chances of this feature being raised and prioritised?