Limit drive-by pull requests on GitHub

How do I limit open pull requests from drive-by contributors on GitHub

Limit drive-by pull requests by controlling what can merge, who can review, and how much work a new pull request creates for maintainers. GitHub does not give you a simple “block all open PRs” switch for public repositories, so the practical answer is to shape the workflow around protected branches, rulesets, templates, and narrow write access. GitHub documents protected branches and rulesets as the mechanisms for enforcing review and status requirements before merge.

The first thing people get wrong is trying to solve this at the pull request list. That is the wrong layer. A drive-by contributor can still open a pull request in a public repository if GitHub allows contributions, but you can stop that pull request from becoming a fast path into the default branch by requiring approving reviews, status checks, and, where useful, code owner review. GitHub says repository administrators or custom roles with the right permission can require a specific number of approving reviews before merge.

Use branch protection or a ruleset on your default branch. Protect the branch that matters, usually main or master, and require at least one approval, successful checks, and, if your project has clear ownership boundaries, code owner review. GitHub’s docs on managing protected branches and managing pull requests both point to these controls as the standard way to keep risky changes out of important branches.

Keep write access narrow. GitHub permissions are role based, and the ability to create a pull request is not the same thing as the ability to merge one. In an organization, give people only the roles they need, such as triage for people who should manage issues and pull requests without write access, and reserve write access for the maintainers who actually merge code. In a personal repository, be selective about collaborators.

Templates are the cheapest way to reduce low-quality pull requests. A pull request template gives contributors a checklist and tells them what a useful PR looks like before they hit submit. Issue templates and contributing guidelines do the same job one step earlier, so the person opening a drive-by request is more likely to read the rules before they start coding. GitHub also supports standardizing PRs with templates, contribution guidance, and repository health files. You can place the guidance in CONTRIBUTING.md and add a pull request template in the repository default branch.

The part people get wrong is thinking templates reduce volume by themselves. They do not. They reduce noise, not access. If your branch is unprotected, a polished bad pull request is still a bad pull request. Templates work best when they force a contributor to answer specific questions, link the issue they are fixing, and state the tests they ran. That shortens review time and makes it easier to close out weak submissions quickly.

Code owners help when drive-by pull requests tend to touch the same sensitive files. GitHub can automatically request review from the right owners when a pull request changes owned code, and protected branches can require those approvals before merge. That is useful when the issue is not the existence of the pull request, but the risk that a contributor who does not know the repository will change core files without context.

If the real problem is repeated low-value or spammy pull requests, use process, not punishment. Tighten your contribution guide, add a pull request template, and explain the exact bar for acceptance. If you need a working reference for a contributor-facing flow, DevConnect shows the kind of simple, reciprocal testing model that reduces random inbound work by making the next step explicit and fair.

A concrete setup for a small repository looks like this: protect main, require one approval and passing checks, add a PR template that asks for purpose, related issue, and test proof, add CONTRIBUTING.md, and keep merge rights limited to maintainers. That combination does not stop someone from opening a pull request, but it sharply limits how much time a drive-by submission can consume. GitHub’s docs support each part of that stack.

The inconvenient part is that you still have to review, close, or redirect open pull requests. GitHub’s controls reduce the cost of handling them, they do not make the queue disappear. If you want fewer open PRs, the practical path is to make the contribution path narrower, clearer, and more review-gated, not to rely on a hidden setting that GitHub does not provide.

For repositories that get a lot of casual contributions, a good policy is: public issues stay open for discussion, pull requests must match the template, and only maintainers can merge. That keeps the repository approachable while stopping drive-by work from landing by default. GitHub’s permission model and pull request standardization tools are designed for exactly that split.

If you want the shortest answer, it is this: protect the branch, require review, narrow merge rights, and make the contribution path explicit with templates and guidelines. GitHub gives you those controls, and together they are the reliable way to limit the impact of drive-by contributors on pull requests.