Pull Requests and Review
Maya's favorites feature is finished on its branch. She could merge it into main herself and be done — but on most teams she doesn't. First, a teammate looks the change over. That pause, on purpose, before the merge, is where a lot of bugs get caught.
She opens a pull request: a formal proposal that says, in effect, "please pull my branch's work into main." Her teammates read the change, comment on it, and approve it before it merges. Review is that human conversation — the team's quality gate, run by people rather than by a machine.
The proposal: a pull request
A pull request is how Maya proposes her change instead of just making it. It bundles up everything on her branch — all her commits, the whole set of edits — and presents it to the team with a title and a description: here's what I changed, and here's why.
The name is literal: she is requesting that someone pull her branch's work into main. Nothing merges yet. The pull request just opens the change up for the team to look at first — it's a proposal, not the act itself.
Review: a second pair of eyes
Once the pull request is open, a teammate reviews it: reads through the change, asks questions, and points out anything that looks wrong or unclear. It's the same instinct as having a second person read an important email before you send it to the whole company.
The review is a conversation. The reviewer might leave comments, request a fix, or suggest a simpler approach; Maya updates her branch and the discussion continues. This back-and-forth is normal and expected — it's the work getting better, not Maya being doubted.
Approval before the merge
On most teams, a rule means the change merges into main only after a reviewer approves it — a thumbs-up that says "this is good to go." Until then it waits. That approval step is the gate: nothing reaches the shared code without at least one other person having looked at it and agreed.
On many teams the rule is enforced automatically: main simply won't accept a merge until a pull request has been approved. The human check isn't optional politeness — it's built into how the code is allowed to move.
Why bother with review
Review does three jobs at once. It catches mistakes before they reach main, while they're still cheap to fix. It spreads knowledge, because now at least two people understand every change. And it keeps main healthy, since nothing lands there unexamined.
There's a second, automatic gate that runs alongside this human one: when Maya opens a pull request, machines can build and test her change too. That's continuous integration, the subject of the next chapter — and pull requests and review are exactly where you'll meet it again in Git, GitHub & GitHub Actions.
- "Review means the team doesn't trust Maya." Review isn't about distrust — even the most senior developers have their changes reviewed. A second reader catches things anyone can miss, no matter how good they are.
- "A pull request pulls files onto your computer." A pull request is a proposal to merge a branch into main, opened for discussion. It doesn't download anything to your machine.
- "Review and automated tests are the same gate." They run side by side but do different jobs: review is human judgment about whether the change is right; tests are a machine checking the code still works.
- "Once a pull request is opened, it's already merged." Opening a pull request only proposes the change. It merges only after someone reviews and approves it.
- Pull requests and review are where human judgment and the automated pipeline meet — the human gate and the machine gate sit on the same change.
- This is the heart of how GitHub works, and how most software teams collaborate day to day.
- Review spreads understanding across the team, so no single person is the only one who knows how a piece of Pageturn works.
- You'll open, review, and approve pull requests for real in Git, GitHub & GitHub Actions; the idea you've just met is that course's central workflow.
Knowledge Check
What does a pull request actually do?
- Proposes merging a branch into main, opened for the team to review
- Downloads the very latest version of all the code to your own laptop
- Merges the branch into main instantly, with no review
- Runs the app so the team can try out the new feature
Why do teams use human review even though they also run automated tests?
- Tests check the code works; review judges if the change is right
- Review is faster than running the automated tests every time
- Automated tests only run after the change is already merged in
- Review is required by law before any new code can ever be merged
When does a reviewed change get merged into main?
- Only after a teammate reviews it and approves
- Immediately when the pull request is first opened for the team
- As soon as the developer finishes writing the code
- Automatically every night, whether reviewed or not
You got correct