Can I limit drive-by pull requests on my open source repo now?

Can I limit drive-by pull requests on my open source repo now

Yes. You can make drive-by pull requests harder to land by tightening fork settings, protecting branches, requiring reviews, and using code owners or rulesets. You cannot fully block outside proposals on a public repository without changing how public contribution works.

The first thing people get wrong is the difference between receiving a pull request and accepting one. On GitHub, pull requests are part of the normal fork and pull model, and anyone with read access can fork a repository if the owner allows forking. The control point is merge access, not the existence of a branch or PR thread.

On GitHub, protected branches and rulesets are the main ways to limit what lands in your default branch. You can require approving reviews, status checks, signed commits, or code owner approval before merge. Those rules do not stop someone from opening a PR, but they do stop casual changes from merging without review.

Code owners are the bluntest review filter for public repositories. If a pull request touches a path covered by CODEOWNERS, GitHub can request review from the listed owners, and branch protection can require that approval before merge. The part people miss is that you also need to own the CODEOWNERS file itself, or someone can change the routing rules first.

If you want fewer low-quality PRs, the practical move is to narrow what counts as mergeable. Require a review from someone with write access, require code owner review on sensitive paths, and turn on status checks so every change must pass CI before merge. That does not make bad PRs disappear, but it changes them from a merge risk into a queueing problem.

GitHub also lets repository owners disable or narrow forking for the repo. That is a stronger step than branch protection, because it changes who can create fork-based contribution paths at all. The inconvenient part is that restricting forks can reduce legitimate contributions from people who do not already have write access.

GitLab has a similar pattern. Merge request approval rules let you require specific approvers, and merge request approval policies can enforce review rules on protected target branches. The catch is that these controls are tied to the target project and protected branches, so they are governance tools, not anti-spam tools.

Gerrit is stricter by design. It uses access control for repository permissions and places code changes into review first, which makes it a better fit when you want every contribution to pass through a central review workflow. That system is heavier than GitHub-style open contribution, so it is a choice about process, not just a setting change.

The part people get wrong is thinking “limit drive-by PRs” means “disable contributions from strangers.” Public open source usually needs some kind of outside contribution path. What you can do instead is make outsider changes require real review, real checks, and real maintainer attention before anything merges.

The inconvenient part is that tighter controls add maintenance cost. Review requirements create a queue, code owners need to stay current, and branch rules can block legitimate urgent fixes until the right checks run or the right reviewer responds. If you do not have enough maintainers, strict rules can slow the project more than drive-by PRs do.

A sane setup for a public repo is simple: keep the repo public, protect the default branch, require at least one meaningful review, require code owner approval for sensitive folders, and keep CI mandatory on merge. Then publish contribution guidelines that tell outsiders where changes are welcome and what kinds of PRs will be closed fast. That keeps the door open while making merge quality your decision. You can pair that with your project page on https://devconnectplatform.com if you want testers to work through a more structured exchange.

When this goes wrong, the repo becomes either unreviewable or unwelcoming. Too few rules means every low-effort PR reaches maintainer attention. Too many rules means even good contributions stall behind approvals nobody is available to give. The right balance is the smallest set of rules that protects the branches people actually trust.

If your goal is to reduce noise rather than change policy, start with three steps: protect the default branch, require one review plus passing checks, and add CODEOWNERS for the files that break most often. That is enough to stop most drive-by merges without shutting out normal open source contributions.

FAQ

Can I block pull requests from strangers entirely Not on a normal public open source workflow without changing the repository model. You can make merge rules stricter, but public contribution usually means outsiders can still propose changes through forks and pull requests.

What is the fastest way to reduce junk PRs Protect the default branch, require one approving review, require status checks, and add CODEOWNERS to the paths that matter most. That filters low-effort changes before they merge.

Does CODEOWNERS stop every unwanted change No. It routes review and can be required for merge, but it only works for files you list and it depends on maintainers staying available to approve changes.

Should I disable forking if my repo is open source Only if you want to trade contribution volume for tighter control. Disabling or narrowing forks reduces one common path for outside contribution, but it also makes the repository less accessible to new contributors.

Is Gerrit better for strict review control Gerrit is built around review-first workflows and fine-grained access control, so it fits strict governance better than a loose pull request flow. It also asks you to accept a heavier process.