CodePulse Research

3.4 Million PRs, One Uncomfortable Truth

What GitHub's largest code review study reveals about how software really ships

83%

No Review

(1000+ line PRs)

68%

Self-Merged

(all PRs)

18x

Less Scrutiny

(large PRs)

53%

Longer Wait

(new contributors)

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

Executive Summary

We analyzed over 3.4 million merged pull requests from GitHub's public archive to understand how code review actually works in practice. What we found challenges the assumption that "code review" is a universal practice.

The uncomfortable truth: The bigger the code change, the less anyone looks at it. 83% of pull requests over 1,000 lines ship without any formal code review.

The Review Crisis: 70-83% of PRs Ship Without Formal Review

We measured the percentage of PRs that receive zero formal code review (no approvals, no change requests, no review comments). The results are striking: across all PR sizes, the majority ship without any documented review process.

PRs Without Formal Review by Size

0%25%50%75%100%<1010-5050-200200-500500-1K1000+

Based on 3,387,250 merged PRs. "No formal review" = zero approvals, zero change requests, zero review comments.

"83% of pull requests over 1,000 lines ship to production with zero formal code review."

What teams can do

  • 1.Set up branch protection rules requiring at least one approval before merge
  • 2.Use CODEOWNERS files to ensure domain experts review their areas
  • 3.Track your team's review coverage rate as a metric (aim for >90% reviewed)

The Self-Merge Reality: 68% of Code Ships Without a Second Pair of Eyes

We compared the PR author to the person who clicked "merge." In 68% of cases, they're the same person. While self-merge can be appropriate (small fixes, sole maintainers), at this scale it suggests "code review culture" may be more aspiration than reality.

Who Merges the Code?

  • Merged by other
  • Self-merged
68%32%

2,346,381 PRs self-merged

Author = Merger (68.03%)

1,102,410 merged by someone else

Different person reviewed (31.97%)

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

The Size Paradox: Large PRs Get 18x Less Scrutiny

Intuition suggests larger changes need more review. The data says the opposite. Review comments per 100 lines of code drops from 0.91 for tiny PRs to just 0.05 for massive ones—an 18x reduction in scrutiny per line.

Review Comments per 100 Lines of Code

<1010-5050-200200-500500-1K1000+00.250.50.751

As PR size increases, reviewers leave exponentially fewer comments per line of code—suggesting cognitive overload and "rubber-stamping."

"The bigger the change, the less anyone looks at it. Large PRs receive 18x fewer review comments per line of code."

What teams can do

  • 1.Enforce PR size limits (e.g., warning at 400 lines, hard block at 1000)
  • 2.Break large features into stacked PRs or feature flags
  • 3.Require multiple reviewers for PRs above a size threshold

The First-Contribution Tax: New Contributors Wait 53% Longer

First-time contributors to a repository wait significantly longer for their PRs to be merged. This "onboarding tax" has real implications for open source sustainability and team onboarding.

Time to Merge: First-Time vs Repeat Contributors

First-time contributors

26h

median time to merge

P90: 305h (12.7 days)

133,315 PRs analyzed

Repeat contributors

17h

median time to merge

P90: 199h (8.3 days)

913,530 PRs analyzed

First-time contributors wait 53% longer (9 extra hours)

"First-time contributors wait 53% longer for their code to be reviewed. The onboarding tax is real."

The Monday Phenomenon: 1 in 5 PRs Merge on Monday

Contrary to the "Friday deploy" meme, Monday is actually the biggest merge day—19% of all merges happen at the start of the week. This suggests teams clear their review backlogs after the weekend.

Merges by Day of Week

SundayMondayTuesdayWednesdayThursdayFridaySaturday0%5%10%15%20%

Monday has the highest merge rate (19.08%), followed by Tuesday (18.05%). Weekend days see the lowest activity.

"Monday isn't just the start of the work week—it's when 1 in 5 PRs finally get merged."

The Always-On Culture: 27% of Code Ships on Weekends

Over a quarter of all code pushes happen on Saturday and Sunday. And 64% of PRs are opened outside traditional 9-5 UTC business hours. The "always-on" engineering culture is reflected in the data.

27.6%

Weekend Pushes

Over 1 in 4 commits

64%

After-Hours PRs

Outside 9-17 UTC

16:00

Peak PR Hour

UTC (4 PM)

Code Push Distribution by Day

SundayMondayTuesdayWednesdayThursdayFridaySaturday0%5%10%15%20%

"27% of code pushes happen on weekends. The always-on culture is real."

Elite Team Benchmarks: From 0 Hours to 4 Days

We analyzed cycle times across notable open source projects. The variance is staggering: VS Code and Homebrew merge PRs same-day, while Zephyr RTOS takes over 4 days median. Context matters—embedded systems demand rigor, package managers value speed.

🚀 Fastest Projects (Median Hours to Merge)

RepositoryMedian Merge TimePRs Analyzed
Homebrew/homebrew-caskSame-day8,060
microsoft/vscodeSame-day1,651
Homebrew/homebrew-core1h8,459
elastic/elasticsearch2h3,030
elastic/kibana3h5,000
grafana/grafana3h2,019
home-assistant/core4h2,843

🐢 Slowest Projects (Median Hours to Merge)

RepositoryMedian Merge TimePRs Analyzed
zephyrproject-rtos/zephyr102h (4.3 days)1,813
llvm/llvm-project23h (1.0 days)5,044
rust-lang/rust22h (0.9 days)1,570
NixOS/nixpkgs20h (0.8 days)13,990
cockroachdb/cockroach19h (0.8 days)2,430

Why the 100x Difference?

  • •Homebrew/VS Code: Automated merge processes, trusted maintainers, package-focused (low risk per change)
  • •Zephyr/LLVM: Safety-critical embedded systems, compiler infrastructure (high cost of bugs)
  • •Your team: Find your context. Don't benchmark against projects with different risk profiles.

"Review time varies 12x across elite projects—from 2 hours to 25 hours."

Language Leaderboard: Fastest to Slowest

Different language ecosystems have different velocities. PowerShell leads with a 6h median (likely due to automated workflows), while C is slowest at 24h.

LanguageMerged PRsMedian HoursAvg PR Size
PowerShell9,0266h307 lines
Dockerfile5,70411h85 lines
C#36,36414h377 lines
Shell29,07715h111 lines
TypeScript204,15216h377 lines
JavaScript89,67816h353 lines
Ruby22,00116h145 lines
Rust45,94218h299 lines
Java77,08620h282 lines
Go72,83720h260 lines
Python129,70221h271 lines
Kotlin24,43521h230 lines

Methodology

Data Source

All data comes from GitHub Archive, a public dataset that records all public GitHub events. We queried the data using Google BigQuery's public dataset.

Sample Size

MetricSample Size
PR size and review analysis3,387,250 merged PRs
Self-merge analysis3,448,791 merged PRs
Contributor analysis1,046,845 merged PRs

Definitions

  • "No formal review": Zero approvals, zero change requests, and zero review comments on the PR
  • "Self-merged": The PR author is the same person who clicked merge
  • "First-time contributor": This is the author's first PR to this repository (within the analysis period)
  • PR size: additions + deletions in lines of code

Limitations

  1. Open source ≠ Enterprise: Public repos have different dynamics than private enterprise codebases. Volunteer contributors, different review cultures, and varying governance models affect metrics.
  2. December timing: December may have different patterns due to holidays and end-of-year pushes.
  3. UTC timezone: All time-based analysis uses UTC, which may not reflect local business hours for globally distributed teams.
  4. Survivorship bias: We only analyzed merged PRs. Abandoned or rejected PRs may have different patterns.

How Does Your Team Compare?

These benchmarks come from public open source projects. How do your private repositories stack up? CodePulse tracks review coverage, self-merge rates, and contributor wait times for your team.

Start Free TrialLearn How It Works

No credit card required. 5-minute setup. Read-only GitHub permissions.