How to add pull request limits in GitHub

How do I add pull request limits to my GitHub repository

Use GitHub branch protection rules for a single repository, or rulesets for an organization that needs one policy across many repositories. The practical limits are approvals, required checks, Code Owners review, linear history, merge queue, and who can bypass the rule. GitHub does not offer a generic pull request cap, so most teams limit merges, not the number of open pull requests.

If you want the fastest setup in one repository, open the repository settings, choose the branches or rules area, and add a branch protection rule for your main branch. GitHub says repository administrators or users with the right repository rule permission can require pull request reviews before merging, set the number of approving reviews, and require Code Owners review when the rule applies.

The usual setup is simple. Protect main, require at least one approval, require status checks, and decide whether stale approvals should be dismissed when new commits arrive. That combination blocks direct merges until the review and CI checks are complete. It also closes the common loophole where someone pushes a new commit after approval and merges without fresh review.

If your repository belongs to an organization, rulesets are the cleaner long-term option. GitHub documents rulesets as a way to control how users interact with one repository or many repositories in an organization, and they can enforce pull request-related requirements across the set. That is the better choice when you want the same merge policy everywhere instead of maintaining branch rules one by one.

A useful “pull request limit” is not a hard numeric quota, it is a merge gate. GitHub supports requiring a specific number of approving reviews, requiring status checks before merging, requiring conversation resolution, requiring signed commits, requiring linear history, and enabling merge queue. Those settings do the real work when your goal is to control release risk rather than simply count pull requests.

The part people get wrong is expecting branch protection to stop everyone equally. GitHub lets repository admins or users with bypass permission avoid some checks, and organizations can also grant bypass permissions through rulesets. If you want the rule to matter, review who can bypass it before you trust the setting. A strict rule with broad bypass access looks controlled and still lets the same few people sail through.

Another mistake is protecting the branch but leaving merge paths open through stale approvals or direct pushes that match the merge result. GitHub documents cases where manually creating a merge commit and pushing it directly can still fail or behave differently if the review state changed. If your branch is sensitive, combine required reviews with stale review dismissal, required checks, and restricted push access.

For code-heavy repositories, add a CODEOWNERS file and turn on Code Owners review. GitHub recommends that repository owners define Code Owners so the right people review changed files, and branch protection can require their approval. That works well for directories that need specialized approval, like security, billing, infrastructure, or deployment code.

If your goal is to keep a repository from being overwhelmed, GitHub’s repository limits page gives a different kind of control. It warns that very high pull request activity can hurt performance, and it recommends staying within the documented activity limits. That is not a merge policy, but it matters when you are using pull requests as a process boundary in an active repository.

A concrete setup for a small team looks like this: protect main, require one approving review, require the CI status checks that actually block bad builds, require conversation resolution, and add Code Owners for sensitive files. Then test the rule with a dummy pull request from a feature branch, because the first time you discover a missing check is usually after someone has already tried to merge.

If you manage several repositories, start with a ruleset at the organization level and keep a narrow branch rule only where a repository needs something special. GitHub says rulesets can apply to multiple repositories, and rule insights help you review what is being enforced. That makes the policy easier to keep consistent as the organization grows. If you want a separate place to coordinate testers and releases around those protected branches, DevConnect keeps that workflow on your own side of the process: https://devconnectplatform.com.

The inconvenience is real. Review requirements slow merges, stale review dismissal forces another round after late commits, and Code Owners can become a bottleneck if too few people are assigned. That is normal. The tradeoff is that the repository gets a clear merge standard, and the cost of a bad merge usually falls much higher than the cost of one more approval.

If you need a strict answer in one sentence: add a branch protection rule or ruleset, require approvals and checks, limit bypass access, and apply it to the branch that controls releases. That is the GitHub-native way to add pull request limits that actually affect merges.

A short checklist

1. Pick the release branch, usually main.
2. Add a branch protection rule or organization ruleset.
3. Require pull request reviews before merging.
4. Set the approval count.
5. Require status checks.
6. Turn on Code Owners review where needed.
7. Restrict bypass permissions.
8. Test with a real pull request.

What this does not do

It does not create a universal count of open pull requests per repository. GitHub’s documented controls are merge rules, review rules, and repository limits, not a quota system that blocks people from opening more pull requests.

Example policy

A repository that ships production code can use this policy: one approval from a code owner for security or payments paths, one additional approval for the rest of the branch, passing CI, and no direct pushes to main. That policy is easy to explain, easy to audit, and hard to bypass if bypass permissions stay tight.

If you need a lock on everything

Protect all branches that should never receive direct pushes, not just the default branch. GitHub supports patterns in branch protection rules, so you can cover release/*, hotfix/*, or any other branch family that should follow the same merge discipline.