Why pull requests get rejected and how to avoid it
common PR rejection reasons, scope creep, missing tests, ignoring style guides, PRs without issue backing, maintainer bandwidth, grace recovery after rejection
Most Rejections Are Preventable
Getting a PR rejected stings. But most rejections share a small set of root causes -- all avoidable with preparation.
The Most Common Reasons
No linked issue or prior discussion. PRs that appear without an issue or comment thread have no context. Maintainers do not know if you have considered edge cases or if the change is wanted at all.
Scope too large. A PR that touches 15 files for a bug that needed 2 is a signal that the contributor did not scope the change. Refactoring and fixes should be separate PRs.
Missing or broken tests. Projects with test suites expect coverage. A PR that drops coverage will be rejected or held until tests are added.
Style guide violations. Inconsistent formatting, wrong indentation, non-idiomatic code -- these are not aesthetic preferences in a large codebase. They create noise in future diffs.
Duplicate PR. Search open and recently closed PRs before submitting. Someone may have already solved the problem.
Recovering from Rejection
If a PR is closed without merge, read the reason carefully. Ask one clarifying question if needed. Do not reopen the same PR -- address the feedback and open a new one. A graceful response to rejection often opens a mentoring relationship with the maintainer.