A pull request is a formal proposal to merge a set of commits from one branch into another, usually into the main branch of a shared repository, together with a page where the changes are reviewed, discussed and automatically tested before integration. Among development tools, it is the central collaboration unit of Git hosting platforms such as GitHub, Bitbucket and Gitea.
GitLab calls the same concept a merge request, and Gerrit organizes review around individual changes. The name comes from the request that a maintainer pull the contributor’s branch into the project. Git itself has no pull request object; the pull request is a platform feature built on top of branches, which adds review comments, approvals, status checks and merge controls.
How a pull request works
A pull request connects a source branch, which holds the proposed commits, with a target branch, often called the base. The platform computes the diff between the two from their merge base, the most recent common ancestor commit, so reviewers see only the changes introduced on the source branch.
- A developer creates a feature branch, commits changes and pushes the branch to the remote repository or to a personal fork.
- The developer opens a pull request with a title, description and linked issue, optionally as a draft.
- Continuous integration runs builds, tests, linters and security scans and reports status checks.
- Reviewers comment on lines, request changes or approve; the author pushes follow-up commits to the same branch.
- When required checks and approvals are satisfied, the pull request is merged and the branch is deleted.
The pull request stays live while the branch changes: every new push updates the diff and reruns checks. If the target branch moves on and touches the same lines, the platform reports a merge conflict, which the author must resolve by merging or rebasing before integration.
Merge strategies for a pull request
Platforms offer several ways to integrate an approved pull request, and the choice shapes the long-term history of the repository. Many teams enforce a single strategy through repository settings.
| Strategy | Resulting history | Advantages | Drawbacks |
|---|---|---|---|
| Merge commit | All commits plus a merge commit | Preserves full context and branch structure | Noisy, non-linear history |
| Squash and merge | One commit per pull request | Clean history, easy revert | Loses individual commit detail |
| Rebase and merge | Commits replayed linearly | Linear history with granular commits | Rewrites commit hashes |
| Merge queue | Each change tested on latest base | Prevents broken main branch | Adds waiting time and infrastructure |
Squash and merge is popular in product teams because each pull request becomes a single revertible unit, while open-source projects with carefully crafted commits often prefer rebase or merge commits. Merge queues address a subtle problem: two pull requests can each pass tests alone yet break the main branch when combined.
Pull requests among related development tools
A pull request is easy to confuse with neighboring Git concepts, because the word pull also names a Git command. The table separates them.
| Concept | What it is | Where it lives |
|---|---|---|
| Pull request | Reviewed proposal to merge a branch | Hosting platform |
| git pull | Fetch remote commits and merge them locally | Local Git command |
| Branch | Movable pointer to a line of commits | Git repository |
| Commit | Snapshot of changes with a message | Git repository |
| Patch by email | Diff sent for review on a mailing list | Email workflow, as in Linux kernel development |
| Merge conflict | Overlapping edits Git cannot combine | Arises during merging or rebasing |
Pull requests also orchestrate other tools: linters and static analyzers post findings as annotations, test coverage services report deltas, and preview environments deploy each branch to a temporary URL. In this sense the pull request is the quality gate of a modern delivery pipeline.
Writing and reviewing effective pull requests
The single most effective practice is keeping pull requests small. Review quality drops sharply as diffs grow, and many teams aim for changes of a few hundred lines at most, focused on one purpose. Large features are split into stacked or incremental pull requests, often behind a feature flag.
- Explain why, not only what: the description should state the problem, the approach and how it was tested.
- Separate refactoring from behavior changes so reviewers can verify each independently.
- Use draft pull requests to share early work without requesting formal review.
- Automate style checks so human reviewers focus on design, correctness and risk.
- Respond to every comment, either with a change or a reasoned reply, before requesting re-review.
Repository rules make the process enforceable. Branch protection can require passing status checks, a minimum number of approvals, review from code owners of affected paths, signed commits and an up-to-date branch before merging.
Common pull request problems
Most dysfunction around pull requests is organizational rather than technical. The table lists recurring symptoms and their remedies.
| Symptom | Likely cause | Remedy |
|---|---|---|
| Pull requests wait days for review | No review ownership or capacity | Review service levels and rotating reviewers |
| Reviews approve without reading | Oversized diffs | Smaller, single-purpose changes |
| Frequent merge conflicts | Long-lived branches | Merge to main daily, use feature flags |
| Main branch breaks after merges | Tests ran on an outdated base | Require up-to-date branches or a merge queue |
| Secrets exposed in history | Credentials committed to the branch | Secret scanning and immediate key rotation |
Security deserves particular attention in open projects. Workflows triggered by pull requests from forks must not receive repository secrets by default, because the proposed code runs in the continuous integration environment and could exfiltrate them.
In plain words
A pull request is like submitting a draft for review before it goes into the final document. A programmer makes changes in a separate copy, then asks the team to look at them. Colleagues leave comments and suggest fixes. Automated checks confirm that nothing obvious is broken.
Only when everyone is satisfied are the changes added to the shared version. The key benefit is a second pair of eyes on every change, plus a written record of why it was made.
A real-world example
A developer at a mid-sized software company fixes a bug in which invoices round tax amounts incorrectly. She creates a branch named fix/invoice-tax-rounding, changes 40 lines in the billing module, adds six unit tests and opens a pull request that links the bug report and explains the rounding rule now applied.
Within minutes, continuous integration runs about 2,000 tests and a linter, and branch protection requires approval from a billing code owner. A reviewer spots an unhandled currency with three decimal places, the author adds a test and a fix, and the pull request is squashed and merged the same afternoon. The fix reaches production with a traceable review record, and the single squashed commit can be reverted in seconds if needed.