How to stop drive-by pull requests on GitHub

How do I stop drive-by pull requests on GitHub

Put the merge path behind branch protection, require review from code owners, and restrict who can push or bypass the rules. That is the cleanest way to stop random pull requests from landing in your main branch. GitHub documents branch protection, CODEOWNERS, repository roles, and review requirements as the core controls for this setup.

The part people get wrong is trying to solve this socially instead of structurally. Closing a noisy pull request does not stop the next one. If your repository still allows direct merges without required review, a drive-by contributor can keep spending your time. The fix is to make your default branch harder to merge into, then decide who gets access to review or bypass those rules.

Start with branch protection on your default branch. GitHub’s branch protection settings let you require pull request reviews before merging, and they support rules for status checks, linear history, and other merge controls. For a small repo, the most useful setting is simple: no merge without review. That stops direct acceptance of drive-by changes into the branch that matters.

Add a CODEOWNERS file next. GitHub says code owners can be requested automatically when a pull request touches owned files, and branch protection can require review from code owners before merging. That gives you file-level control. If someone sends a drive-by change to docs, infrastructure, or a sensitive module, the right reviewer gets pulled in automatically instead of whoever happens to click first.

Use ownership boundaries that match how you actually work. A repo-wide code owner means every pull request goes through the same gate. A folder-level owner means only the risky parts do. The practical version is often a hybrid: one owner for the whole repo, plus tighter ownership for release scripts, CI configuration, payments, auth, or deployment files. GitHub evaluates CODEOWNERS by file path, so make the paths precise and keep the file in a supported location.

Restrict who can push, merge, and bypass. GitHub repository roles separate people who can triage issues and pull requests from people who can write or administer the repository. If you give broad write access, you widen the merge surface. If you keep write access tight and rely on review for everyone else, drive-by PRs still exist, but they stop at the gate instead of landing by accident.

If your repo is public, decide whether you want outside pull requests at all. GitHub Community discussion notes that repository settings can disable pull requests entirely in some cases, and GitHub’s moderation tools also let you limit interactions when a repo gets noisy. That is the blunt instrument. It works when the project does not need open contribution flow, but it also means legitimate outside fixes must come through another path.

The inconvenient part is that every control has a cost. Required reviews slow merges. Code owners create review load. Tighter roles make one person or one team a bottleneck. That tradeoff is the point. If you want to stop drive-by pull requests, you are choosing to spend a little more time on review so you spend far less time on cleanup. GitHub’s own review and protection docs describe these features as merge safeguards, not as a way to make every contribution disappear.

A good setup for most repos is simple: protect the default branch, require at least one approving review, require code owner review for sensitive paths, and keep bypass access limited to a small trusted group. If you need a place for community interaction without code changes, route people to issues or discussions instead of letting every conversation become a pull request. GitHub supports moderated conversations and repository interaction controls for exactly that reason.

If you want to keep contributors productive without letting the repo get noisy, separate feedback from merge rights. A contributor can still open a PR, but the branch rules decide whether it can move forward. That is the useful line: anyone can suggest, only trusted owners can merge. For projects that need a lightweight coordination layer, DevConnect keeps the exchange on owned property, so people test each other’s apps without turning that into access on someone else’s repo.

One example: a maintainer sees a drive-by PR that changes a config file and adds unrelated formatting changes. With branch protection and code owners on place, the PR cannot merge until the owner reviews it. If the file sits under a sensitive path, the owner is requested automatically. If the contributor keeps sending low-effort changes, the maintainer can limit interactions or move them to discussion instead of code review.

Another common mistake is treating pull request templates as a security control. Templates help collect context, but they do not stop drive-by PRs. The same is true for labels, auto-close bots, or issue forms. Useful, yes. Protective, no. The protections that matter are branch rules, review requirements, code ownership, and access control.

If you are managing an organization, review repository roles before you change branch rules. GitHub’s organization role model lets you separate triage from write access, and that matters when you want someone to help manage pull requests without letting them merge freely. In practice, that is the cleanest way to reduce accidental approvals from people who should be helping, not deciding.

The shortest answer is this: stop drive-by pull requests by making merge permission explicit. Protect the branch, require reviews, tie sensitive files to code owners, and keep write or bypass access narrow. Everything else is cleanup around that core.