Pull request
Also known as: PR, merge request, pull requests
A pull request (PR) is a request to merge a set of code changes from one branch into another, usually the main project.
It shows exactly what changed, lets teammates comment and suggest edits, and runs automated tests before anything is merged. GitLab calls the same idea a merge request. While pull requests slow things down slightly, they catch bugs, spread knowledge, and create a record of why changes were made.
Pull request, explained at three levels
At home
A pull request is like handing an essay to a friend for proofreading before submitting it. They mark changes, and you fix them before it's final.
At work
Pull requests make sure at least one other person checks code before it goes live.
At home
On GitHub, you can suggest a fix to an open-source project by making changes in your own copy and opening a pull request for the maintainers to review.
At work
Good pull requests are small, focused, and well described. Required reviews, automated tests, and status checks can block merging until standards are met.
At home
Contributing to open source through pull requests is a great way to learn and build a portfolio. In my opinion, start with documentation fixes.
At work
Track review times and pull request sizes as delivery health signals, use code owners for sensitive areas, treat AI review comments as suggestions, and be careful running automated workflows on pull requests from outside contributors.
Real-world examples
At home
Carlos found a typo in an open-source app's documentation. He opened his first pull request, and the maintainer merged it the next day.
At work
Nadia leads engineering at a Toronto health software firm. Every pull request needs two approvals and passing tests, which caught a data bug before release.
How it compares
| feature | Pull request | Merge request |
|---|---|---|
| Platform | GitHub, Bitbucket | GitLab |
| Purpose | Review and merge changes | Review and merge changes |
| Features | Comments, checks, approvals | Comments, checks, approvals |
| Difference | Name only | Name only |
Pull requests and merge requests are the same idea with different names.
For analysts
I'd link pull requests to requirements or tickets. It creates traceability from business need to code change, which auditors and future teams appreciate.
History & origin
Formal code inspections were developed by Michael Fagan at IBM in the 1970s, though they relied on meetings and printed code. Open-source projects reviewed changes by emailing patches, a practice the Linux kernel still uses. GitHub introduced pull requests in 2008, turning review into a simple web experience with comments beside the code, and the idea spread across the industry. Automated checks, from tests to security scans, became part of pull requests through tools such as GitHub Actions in 2019. By 2025, AI code review assistants commonly left comments on pull requests. In my view, the pull request is where software teams learn from each other most.