Pull request
pull reh-KWEST (or just pee-ar)
A proposal to merge code changes from one branch into another, with review.
A PR (pull request) is a request to merge code changes from one branch into another, typically from a feature branch into main. It is the primary mechanism for code review in modern software development.
When a developer opens a PR, they are saying: "Here are my changes. Please review them before they become part of the codebase." The PR shows exactly what changed: lines added, lines removed, files modified. Reviewers can comment on specific lines, request changes, or approve.
PRs are not just a quality gate. They are documentation. Every PR captures the what (the diff), the why (the description), and the discussion (the review comments). Six months later, when someone asks "why was this code written this way?" the PR has the answer.
Examples
A developer submits code for review.
The PR modifies 4 files, adds 200 lines, and removes 50. The description explains the change, links to the issue it fixes, and includes screenshots of the new UI. Two reviewers approve it. One suggests a minor improvement that gets incorporated before merge.
A PR fails CI checks.
The developer opens a PR and the automated test suite runs. Three tests fail because the new code broke an existing feature. The developer sees the failures in the PR checks, fixes the code, pushes an update, and the tests pass on the second run.
A large PR causes review fatigue.
A developer opens a PR with 2,000 lines changed across 30 files. Reviewers skim it and approve without thorough review because the diff is overwhelming. The team adopts a policy: PRs should be under 400 lines. Smaller PRs get better reviews and ship faster.
In practice
Read more on the blog
Frequently asked questions
What is the difference between a pull request and a merge request?
They are the same thing with different names. GitHub calls them pull requests (PRs). GitLab calls them merge requests (MRs). Both are proposals to merge code changes with review.
How big should a pull request be?
Under 400 lines of changes is ideal. Research shows that review quality drops sharply above that threshold. If a feature requires more changes, break it into a stack of smaller PRs that build on each other.
Related terms
A parallel version of the code that lets developers work on changes without affecting the main codebase.
The practice of having other developers examine code changes before they are merged.
Combining code changes from one branch into another, integrating the work.
Continuous integration and continuous deployment: automating code testing and delivery to production.
"Looks Good To Me" -- a code review approval indicating the reviewer is satisfied with the changes.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.