A place to review before merging
A pull request asks for review and discussion before the changes on one branch are taken into another. GitHub abbreviates it to PR; GitLab calls the equivalent a merge request.
Once you name the working branch and the destination, you get the changed files, the diff, and the commits in one view, with comments, reviews, and test results attached to the same place.
How it differs from pull and merge
- Pull: a Git operation bringing remote changes into your local branch
- Pull request: a collaboration feature for reviewing and proposing a merge between branches
- Merge: the operation that actually combines two branches’ histories
Despite the name, it is not a button that runs git pull. Think of it as the discussion venue that precedes a merge.
Useful even working alone
Pull requests are not only for teams. Working solo, they still record why a change was made, what you verified, and screenshots of the result.
When an AI wrote the code, sending it through a pull request rather than straight to main gives you a diff to check for changes you did not ask for and for whether the tests pass.
Before you open one
Normally you push the working branch to GitHub first. If review asks for changes, pushing more commits to the same branch updates the pull request.
Deleting the branch after merging leaves the merged changes and the pull request record intact.
The destination is called the base branch and the source is the head branch. Reversing them produces an unexpectedly enormous diff, so confirm the direction — from where, to where — before creating it.
Even after approval, check the test results and whether new commits arrived just before merging. Some teams push changes after approval, so the final diff is what matters.