Before your changes go into the real version, someone else takes a look. A pull request is how you ask.
At work, you might write a proposal and ask a colleague: “Could you read this before we send it?” They add comments. You fix a few things. Then it goes out.
In Git, a pull request is that “please check this” step. You ask for your branch to be merged. Others review the changes first.
What happens in one
- You finish some work on a branch and open a pull request.
- The website shows exactly what changed, line by line.
- Colleagues leave comments and suggestions.
- Automatic checks often run tests at the same time.
- Once it’s approved, the branch is merged into main.
Why the odd name?
You’re asking the project’s owners to pull your changes into theirs. Some websites, like GitLab, call it a merge request, which is clearer.
What it isn’t
It isn’t part of Git itself. Pull requests are a feature of websites like GitHub, built on top of Git.
It also isn’t only about catching mistakes. Reviews spread knowledge, so more than one person understands each change.
Where the comparison breaks down
A colleague reads your proposal once. A pull request can go back and forth many times, with new commits added as you fix things.
How the words fit together
You work on a branch, open a pull request on GitHub, get it checked, then merge it into main.
Small pull requests get checked faster and more carefully. Ten small ones beat one huge one that nobody wants to read.
When you'll hear it
“Can you review my PR?” Can you check my changes before they're merged?
“I left some comments on your PR.” I've read your changes and suggested a few improvements.
“The PR is approved.” Someone has checked it and it's ready to merge.
“Who needs to approve this before it goes live?”
Try it yourselfReady to use it? The exact commands are on my other site, devcmds: Open a pull request from the terminal ↗
