PR Size

What Is PR Size?

PR size refers to the volume of code changes contained in a single pull request, typically measured by the number of lines added, modified, or deleted. It is one of the most influential factors in determining the quality, speed, and effectiveness of code review. A small PR might change 50 lines across two files; a large PR might touch 2,000 lines across thirty files.

While there is no universally standardized way to calculate PR size, the most common approach counts the total number of lines in the diff — additions plus deletions. Some teams use more nuanced measurements that weight modifications differently from new code, exclude auto-generated files, or factor in the number of files changed alongside line count. Regardless of the exact formula, the principle remains consistent: smaller pull requests lead to better outcomes across nearly every dimension of software development.

PR size is not just a technical metric — it is a leading indicator of team health. Teams that consistently produce small, focused pull requests tend to have faster review cycles, fewer production defects, higher reviewer engagement, and better knowledge distribution. Teams that routinely merge large PRs experience the opposite: slow reviews, more bugs, rubber-stamping, and knowledge silos.

How It Works

PR size is calculated from the diff between the source branch and the target branch at the time of review. Git hosting platforms like GitHub, GitLab, and Bitbucket display this information automatically on every pull request.

A typical size classification system looks like this:

XS:    1-10 lines changed      → Trivial fix, typo, config change
S:     11-100 lines changed    → Small feature, bug fix, refactor
M:     101-400 lines changed   → Standard feature work
L:     401-1000 lines changed  → Large feature, needs careful review
XL:    1000+ lines changed     → Should almost certainly be split

GitHub labels can automate this classification using a simple GitHub Actions workflow:

name: PR Size Label
on: [pull_request]
jobs:
  size-label:
    runs-on: ubuntu-latest
    steps:
      - uses: codelytv/pr-size-labeler@v1
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          xs_max_size: 10
          s_max_size: 100
          m_max_size: 400
          l_max_size: 1000

When evaluating PR size, it is important to account for context. Not all lines are created equal. A 500-line PR that adds a new database migration with generated schema files is fundamentally different from a 500-line PR that rewrites core business logic. Some teams exclude certain file types — such as lock files, generated code, and test fixtures — from their size calculations to get a more meaningful signal.

The relationship between PR size and review quality follows a well-documented curve. Research from Cisco’s SmartBear study of 2,500 code reviews found that defect detection rates peak when reviews examine fewer than 400 lines of code at a time. Beyond that threshold, reviewer attention drops sharply, and the rate at which defects are found per line of code decreases.

Why It Matters

PR size is the single most controllable factor that influences code review effectiveness. While you cannot easily change your team’s expertise or the complexity of your domain, you can always choose to break a large change into smaller pieces.

The data is unambiguous. Google’s internal research across thousands of engineers found that PRs with fewer than 100 lines changed had a median review time of under 1 hour, while PRs over 1,000 lines had a median review time exceeding 1 day. Microsoft’s study of code review practices found that large PRs were rubber-stamped more than 50 percent of the time — reviewers simply could not sustain the attention required to meaningfully examine a massive diff.

Small PRs also reduce risk. When a 50-line change introduces a bug, the blast radius is small and the cause is easy to identify. When a 2,000-line change introduces a bug, debugging requires examining a vast surface area, and the fix often interacts with other parts of the same large change. Small PRs make git bisect effective; large PRs make it nearly useless.

From a deployment perspective, small PRs enable continuous delivery. A team that merges ten small PRs per day can deploy incrementally, roll back individual changes, and maintain a steady flow of value to users. A team that merges one large PR per week is forced into batch deployments with higher rollback costs and longer feedback loops.

Best Practices

• Target 200 lines or fewer per PR. While the commonly cited threshold is 400 lines, Google’s data shows that the sweet spot for review quality and speed is closer to 200 lines. Treat 400 as an upper limit, not a target.

• Use stacked PRs for large features. When a feature requires 1,500 lines of changes, break it into a chain of dependent PRs that can be reviewed and merged sequentially. Tools like Graphite, ghstack, and git-town make stacked PR workflows manageable. Each PR in the stack should be independently reviewable and, ideally, independently deployable.

• Separate refactoring from feature work. A PR that simultaneously refactors existing code and adds new functionality is harder to review than two separate PRs — one for the refactor and one for the feature. Mixing concerns inflates PR size and forces reviewers to track two different types of changes simultaneously.

• Exclude generated files from size calculations. Lock files, compiled assets, and auto-generated code should not count toward your PR size metrics. Configure your analytics tools and labelers to ignore these files so that size measurements reflect the actual volume of human-authored changes.

• Add PR size gates to your CI pipeline. Configure an automated check that flags or blocks PRs above a certain threshold (such as 500 lines). This creates a forcing function that encourages developers to decompose work earlier in the process rather than discovering the size problem at review time.

Common Mistakes

• Splitting PRs arbitrarily to hit a number. Breaking a cohesive 600-line change into two 300-line PRs that cannot be understood independently is worse than leaving it as one PR. Each PR in a split should be a logical, self-contained unit of work. Split along functional boundaries, not arbitrary line-count thresholds.

• Ignoring PR size because “this change cannot be broken up.” In practice, nearly every large change can be decomposed with sufficient planning. Database migrations can be separated from application code. Interface changes can be introduced before their implementations. Test additions can precede the code they will eventually cover. The belief that a PR is indivisible is usually a planning problem, not a technical constraint.

• Counting only additions and ignoring deletions. A PR that deletes 800 lines and adds 50 lines is a net reduction in code, but the reviewer still needs to verify that the deletions are safe. Total churn (additions plus deletions) is a better measure of review effort than net change. A “cleanup” PR that removes dead code still demands careful review to confirm nothing was deleted prematurely.