Code Review Culture

The Self-Merge Reality

Two-thirds of all code on GitHub is merged by the same person who wrote it.

68.03%

Self-Merged

of all PRs on GitHub

Based on 3,387,250 merged PRs | GitHub Archive / BigQuery | December 2024

The Numbers

Our analysis of 3,387,250 merged pull requests reveals a stark reality: the vast majority of code ships without a second pair of eyes.

Who Merges the Code?

  • Merged by Other
  • Self-Merged

2,346,381

Self-merged PRs (68.03%)

1,102,410

Merged by other (31.97%)

"Two-thirds of all code on GitHub is merged by the same person who wrote it."

When Self-Merge is Fine

Self-merging isn't inherently problematic. There are legitimate scenarios where requiring a second reviewer adds friction without adding value.

Solo Projects & Personal Repos

Individual developers working on personal projects have no one to review their code. Self-merge is the only option, and that's perfectly fine.

Hotfixes & Emergency Patches

When production is down, waiting for a code review isn't practical. Trusted engineers need the ability to push fixes immediately.

Trusted Maintainers

Senior maintainers with deep domain knowledge may not need review on routine changes. Their experience is the review.

Documentation & Config Updates

README updates, configuration tweaks, and non-functional changes often don't need the same rigor as production code.

"Code review isn't the norm. It's the exception."

When Self-Merge is a Red Flag

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.

Warning Signs

  • Enterprise production code: Teams that claim to have "code review" but show 60%+ self-merge rates
  • Security-sensitive areas: Auth, payments, or data handling merged without a second set of eyes
  • Large refactoring changes: Major architectural changes that bypass team review
  • Junior developer code: New team members merging without mentorship opportunities

What "Code Review Culture" Actually Means

Many organizations claim to have a strong code review culture. But the data tells a different story. When two-thirds of code merges without a reviewer, "culture" is aspirational, not actual.

What They Say

"All code must be reviewed before merge. We take code quality seriously."

What The Data Shows

68% of PRs merge without a different person involved. Review is optional in practice.

True code review culture requires more than policy—it requires tooling that enforces it, time allocated for it, and metrics that track it.

🔥 Our Take

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." If your team's self-merge rate is above 50%, you don't have a code review culture—you have a code review aspiration.

What Teams Can Do

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.

Require Different Reviewers

Configure rules so that the PR author cannot approve their own changes. Self-approval defeats the purpose of review.

Use CODEOWNERS

Automatically request reviews from domain experts. CODEOWNERS ensures the right people see changes to critical paths.

Track Your Metrics

You can't improve what you don't measure. Monitor self-merge rates, review time, and reviewer distribution to understand your actual review culture.

Related Research

Methodology

This analysis is based on 3,387,250 merged pull requests from GitHub Archive / BigQuery during December 2024. A PR is classified as "self-merged" when the merge was performed by the same GitHub user who opened the PR. This includes bot PRs where bots may self-merge automated changes. For full methodology, see the complete study.

See your team's self-merge rate

CodePulse shows you exactly who's merging what in your repositories.