Repository owner merging own pull requests

[marykarampour]

Select Topic Area

Product Feedback

Body

Assuming I am the owner of a repository. I set a rule to require at least one reviewer for pull requests to be approved. As a side effect, this prevents me from merging my own pull requests. It would be natural to be able to add a bypass, an exception, for example: "Owner can merge their own pull requests without a reviewer", or "Count the owner as a reviewer for all pull requests", something like that. Without this, I have to first set required reviewers to 0, merge, then go back and set it to 1 again! This hassle is unnecessary.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[thevindu-w]

There's an option in branch protection rules that allow/disallow repo admin to bypass branch protection rules (and merge PR without reviews)

Uncheck this option to merge your PR without reviews.

If you are using rulesets, add yourself to the bypass rules option.

[marykarampour]

I have added myself in a bypass, but I can't find the option: "Do not allow bypassing the above settings" where is this?

This is what I see:

[thevindu-w]

I can't find the option: "Do not allow bypassing the above settings" where is this?

It's only for branch protection rules. It's not in rulesets which you are using. Check if there are branch protection rules also created at https://github.com/<username>/<repo>/settings/branches. If there are no branch protection rules, that means you only have rulesets. If there is only one ruleset, and if it's the one shown above, you should be able to merge without approvals if your role is "Repository admin".

[marykarampour]

Thanks. But unfortunately it doesn't work as one would expect. The only rule I had was the ruleset, no branch rules. I tried with only branch rule, or with only ruleset. Neither let me merge. In both cases I get this: "Pull request authors can’t approve their own pull request." It looks like it can't recognize that the author is the owner / admin even with bypass.

This is the only thing that seems to make it work. This seems unnecessarily complicated to me maybe because these things are very straightforward in BitBucket, GitLab etc. that I use.

[thevindu-w]

You can't approve your own PR. But, you don't need to approve it anyway. In the 2nd screenshot, you can check the "Merge without waiting for requirements to be met" option and merge it. So, you don't need to change rulesets to remove the required approvals rule to merge it.

[marioepsilon]

Yes, that's right, I was just thinking if other people find it reasonable, the process could potentially be made a bit more simplified and straightforward and less confusing, e.g., that red alert is really redundant in this case. If others don't care, the way it is, certainly does the job.

Thanks

[ijstokes]

I am with @marioepsilon -- good practice suggests there should be a code review on every PR, even if I do my own code review on the PR and approve it. This means the protocol is always followed. I'm here because I've just spent 30-60 minutes messing around trying to figure out exactly this issue. At least I know I'm not going crazy missing something -- it just isn't possible, and the documentation doesn't make that clear.

[kalazzz]

Yeah totally agree, The red warning tells my brain that something isn't being met. For example with one rule-set I have set, every time files are added or deleted in main brunch it will not allow it. So the red warning for me is like an extra step saying "Warning are you sure you want to do this merge, it doesn't follow your usual requirements/rules" ... and it signals my brain that something weird or extra is happening.

If bypassing the list for any reasons isn't the solution, an option to allow the author to self review would be nice (Especially when the brunch has code from other people as well, even if it's created by the author).

Some extra information

Generally bypassing though should always mean for me "Don't follow the rule for that group of people", so I really think the way github is using it is weird

Let's say for example I have 2 rule-sets:

1. Don't allow deletion of files in main brunch + Don't allow addition of Files in main brunch
2. Don't allow self review

What happens currently in github

Right now if you don't add yourself in the bypass list for the first ruleset the red button won't even appear (to allow you to continue), this is fine for me, but as we said above it creates at least 2 problems.

1. Using the red color for 2 factor bypassing authentications signals that something wrong is happening (even though it's just your rule-sets and bypassing following exactly the rules you told them to follow)
2. It doesn't create a bypass for self-review. This may be a different problem but still it's there right now.

What should happen

I am fine with 2 factor/steps bypassing, I think it's good practice. But I think it should be signaled with yellow instead of red. And red should be there only when other users don't follow those rules and you in the bypass list are the one agreeing to bypassing them.

Generally I think github needs more advanced rules and role permissions

[argenis972]

What you’re seeing is expected behavior with branch protection rules. When “Require pull request reviews before merging” is enabled, GitHub enforces the same rule for everyone — including repository owners — unless you explicitly configure a bypass.

A few options you can consider:

1. Allow specific bypass actors (recommended)
   If you’re using the newer “Rulesets” instead of classic branch protection:

• Go to Settings → Rules → Rulesets
• Edit your ruleset
• Add yourself (or a specific role/team) under “Bypass list”
  This allows you to merge without approvals while keeping the rule for others.

2. Use admin bypass (if enabled)
   In classic branch protection:

• Check if “Allow administrators to bypass” is enabled
  If you are an admin, you may be able to merge despite missing approvals.

3. Use a separate protected branch workflow
   Some teams keep strict rules on main but allow owners to merge into an intermediate branch (e.g., maintainer-merge) and then merge via automation.

4. Self-approval is intentionally restricted
   GitHub generally prevents authors from approving their own PRs to preserve review integrity, so counting the owner automatically as reviewer is not currently supported behavior.

If you’re not seeing bypass options, you may still be using classic branch protection instead of Rulesets — migrating to Rulesets gives more granular exceptions.

[rogerfar]

There is an issue with this approach though, we have workflows that run only when a PR is approved, and this becomes a check on the ruleset.

Because an author cannot approve their own PR, this workflow will never run, the check will never complete thus cannot merge properly without bypassing all protection mechanisms.