How to limit drive-by pull requests on GitHub

How can I limit drive-by pull requests on my GitHub repo

You can reduce drive-by pull requests by tightening branch rules, requiring review, and making the repo’s contribution path clearer. If you need a hard stop, GitHub also lets you restrict or disable pull request access for a repository.

The part people get wrong is trying to solve this only with social cues, like a README note or a short template. Those help, but they do not block low-effort PRs. If you want fewer random changes, the controls have to live in repository settings, not just in the prose around them.

Start with branch protection or a ruleset on the branches you actually merge into. GitHub lets repository admins require pull request reviews before merging, require status checks, require conversation resolution, and require a pull request before changes can land on a protected branch. That is the cleanest way to stop casual drive-bys from going straight to main.

If you use required reviews, do not stop at the minimum toggle. One review can still let in rushed or incomplete changes, so the practical setup is usually: at least one approval, required status checks, and stale review dismissal when new commits arrive. That combination forces each PR to survive a real check, not just a quick thumbs-up.

The inconvenient part is that tighter branch rules also slow your own team. If you require reviews, every merge now waits for a reviewer. If you require status checks, broken CI blocks merging. If you require conversation resolution, someone has to clean up every unresolved thread before the button turns green. That friction is the point, but it is still friction.

Use contributor guidance to filter out weak submissions before they start. GitHub supports CONTRIBUTING.md files, and those guidelines are shown to people when they open a pull request or issue. Pull request templates do the same job for the PR itself, because they can ask for the reason for the change, the test plan, screenshots, or links to related work.

This is where many repos miss an easy win: they tell people to contribute, but they do not tell them what a good contribution looks like. A template that asks for a problem statement, reproduction steps, and proof of testing will not stop every drive-by PR, but it raises the cost of sending something vague. People who cannot answer those prompts often self-select out.

If your repo is public and you want to narrow the blast radius further, GitHub also lets you modify pull request access for the repository, or disable pull requests entirely. GitHub’s docs frame this as an option when you want to restrict contributions or turn them off. That is the bluntest tool, and it is appropriate when the repo is not meant to accept broad outside code changes.

A softer version is to keep the repo open, but route people into a workflow you can handle. For example, use issue templates or discussions for feature proposals, then only accept pull requests after a maintainer has confirmed the work is in scope. GitHub supports Discussions as a place to talk without opening an issue, and templates help standardize what people submit.

Another useful control is review ownership. GitHub lets you define CODEOWNERS so the right people are automatically asked to review changes that touch specific files. That does not stop a pull request from being opened, but it does prevent random changes from slipping past the people who know the area best. For a repo with sensitive paths, this is usually more effective than a single global reviewer pool.

You should also keep an abuse response path ready. GitHub lets repository owners and collaborators report pull requests, issues, comments, and users for abuse or spam. If a wave of drive-by PRs becomes harassment or spam, do not just merge around it or argue in the thread, use the reporting tools and tighten interaction limits.

The part people get wrong here is assuming all PR noise is the same. It is not. Some unwanted PRs are just unhelpful. Others are spam, fishing for attention, or attempts to sneak in unsafe code. Your response should match the pattern. Tighter rulesets and templates handle low-quality contributions. Reporting and interaction limits handle abuse.

If you still want outside contributions, but fewer of them, make the path narrower instead of invisible. Require a linked issue, ask contributors to describe the use case, and make it clear which file areas are welcome. GitHub’s templates and contribution guidelines are the place to say that. A clear path usually cuts down the random PRs faster than a vague “please be thoughtful” note ever will.

A practical setup for most repos is this: protect the default branch, require at least one review, require checks, add a PR template, add CONTRIBUTING.md, and define CODEOWNERS for sensitive paths. If noise is still high, limit interactions or disable pull requests on that repository. That gives you a graduated ladder from soft filter to hard stop.

If you want to keep the repo welcoming while reducing junk, start with documentation and branch rules. If you want to make the repo intentionally closed, disable or restrict pull requests and say so plainly in the repository itself. The right answer depends on whether you want fewer drive-bys, or whether you do not want open contributions at all.