Nearly three-quarters of code on GitHub is merged by the same person who wrote it—and it's getting worse.
Self-Merged
of all PRs on GitHub (2025)
Based on 802,979 merged PRs | GitHub Archive / BigQuery | October 2025
Self-merge rates have climbed from 68.03% in 2024 to 71.48% in 2025—a +3.45 percentage point increase. More code is shipping without peer review than ever before.
2024 Self-Merge Rate
68.03%
2025 Self-Merge Rate
71.48%
+3.45pp YoY
573,883
Self-merged PRs (71.48%)
228,935
Merged by other (28.52%)
"Nearly three-quarters of all code on GitHub is merged by the same person who wrote it—up 3.45 points from last year."
The 71.48% self-merge rate is the global average—including solo projects, hobby repos, and unmaintained code. When we filter to PRs that actually receive code review, the picture changes significantly.
All GitHub PRs
71.48%
802,979 PRs analyzed
Includes solo projects, hobby repos, self-merged code
Reviewed PRs Only
52.11%
117,390 PRs with reviews
PRs with code review - more representative of team workflows
A 19pp gap
In repos that practice code review, self-merge drops by nearly 20 percentage points. This suggests branch protection rules and review requirements work—when they exist.
"In reviewed repos, self-merge drops to 52%. The difference is branch protection rules—not culture."
Self-merging isn't inherently problematic. There are legitimate scenarios where requiring a second reviewer adds friction without adding value.
Individual developers working on personal projects have no one to review their code. Self-merge is the only option, and that's perfectly fine.
When production is down, waiting for a code review isn't practical. Trusted engineers need the ability to push fixes immediately.
Senior maintainers with deep domain knowledge may not need review on routine changes. Their experience is the review.
README updates, configuration tweaks, and non-functional changes often don't need the same rigor as production code.
The problem arises when self-merge becomes the default for code that should be reviewed. High self-merge rates in certain contexts indicate broken processes.
Self-merge isn't inherently bad—context matters.
Solo maintainers, trusted senior engineers, and hotfixes often don't need a second pair of eyes. The problem is when self-merge becomes the default for production code in teams that claim to have "code review."
The 19pp gap between global (71%) and reviewed (52%) repos tells the story: branch protection rules work. If your team's self-merge rate is above 50%, you don't have a code review culture—you have a code review aspiration. Enable branch protection.
GitHub's branch protection rules can require at least one approving review before merge. This is the minimum bar for production branches.
Configure rules so that the PR author cannot approve their own changes. Self-approval defeats the purpose of review.
Automatically request reviews from domain experts. CODEOWNERS ensures the right people see changes to critical paths.
You can't improve what you don't measure. Monitor self-merge rates, review time, and reviewer distribution to understand your actual review culture.
This analysis is based on 802,979 merged pull requests from GitHub Archive / BigQuery during October 2025. A PR is classified as "self-merged" when the merge was performed by the same GitHub user who opened the PR. The "reviewed PRs" benchmark (117,390 PRs) filters to only PRs that received at least one code review event. For full methodology, see the complete study.
CodePulse shows you exactly who's merging what in your repositories.