🔍 Pull requests: how teams review work

How your branch gets a friendly second look before it joins the official album.

1The problem pull requests solve

When you work alone, the photo album is yours. You glue photos in whenever you like. On a team, the album belongs to everyone. If anyone could glue pages in unseen, one bad photo could break the album for the whole group.

📔 Nobody glues pages into the shared album unseen. Before new work joins the official line, a teammate glances at it first. A second pair of eyes catches bugs, spreads knowledge around the team, and keeps main always working, always ready to ship.

So the team habit is simple: do your work on a branch, then ask someone to look before it merges. GitHub has a whole feature built around exactly this ask.

🗣 GitHub's word for this is a "pull request," or PR for short. A pull request says: here is my branch, please review it, then press the button to merge it. The name reads from the project's point of view: you are requesting that the project pull your work in. And note: this is a GitHub feature, not a git command. You will never type git pull-request in the terminal.

2The life of a pull request: Sam fixes a typo

Meet Sam. Sam notices the signup page says "Welcom." Tiny fix, but it still gets the full routine, because the routine is cheap. Here is Sam's terminal:

# 1. make a bookmark for the fix
git switch -c fix-signup-typo
Switched to a new branch 'fix-signup-typo'

# 2. fix the typo, basket it, take the photo
git add signup.html
git commit -m "Fix typo on signup page"

# 3. send the branch up to GitHub
git push -u origin fix-signup-typo
remote: Create a pull request for 'fix-signup-typo' by visiting:
remote:   https://github.com/team/project/pull/new/fix-signup-typo

The -u just asks git to remember the pairing between the local branch and its GitHub copy. From then on, plain git push is enough. (Older guides write git checkout -b instead of git switch -c: same idea, older word.)

Now GitHub takes over. It noticed the new branch and shows a green button: "Compare & pull request." Sam clicks it and writes a title plus a short description: what changed and why, like a commit sticky note with more room. Then:

Teammates read the change and comment on specific lines.
Sam fixes the feedback by pushing more commits to the same branch. The PR updates by itself. No restart, no new PR.
Someone clicks Approve, then Merge. Sam's photos join the official line.
The branch gets deleted. Remember lesson 4: a branch is a bookmark, not a copy. Deleting it throws away a sticky bookmark, never the photos.

3Reviews are conversations, not exams

Review comments attach to exact lines of your change, so the discussion is always about something concrete. You reply, you push a fix, you re-request review. That loop can run two times or ten times. The PR keeps up automatically.

✍️ An editor reads your article before it goes to print. Not because you are bad at writing, but because every writer benefits from an editor. A code review works the same way: a teammate reads your change before it goes live, and both of you learn something.

On healthy teams, reviews include praise and suggestions, not just objections. "Nice fix" is a valid review comment. And remember: nothing is at risk while a review happens. Your commits sit safely on your branch the whole time. A review is a conversation about the work, never a grade on you.

4The three merge buttons

When the PR is approved, GitHub's green merge button hides a small dropdown with three choices. In album words:

Button	What it does
Create a merge commit	Ties the two ends together with one two-parent photo, exactly like case 2 in lesson 6.
Squash and merge	Flattens all the branch's photos into ONE tidy photo on main; the most common team default, because it keeps main readable.
Rebase and merge	Replays the photos one by one onto main; advanced, and fine to ignore for now.

Beginner rule: use whatever your team uses. When in doubt, squash.

5What makes a PR easy to say yes to

Reviewers are people with their own work to do. Three habits make them happy to press Approve:

Small. One idea per PR. A ten-line fix gets reviewed in minutes; a thousand-line epic sits for days.
Described. Say what changed, why, and how to test it. The reviewer should never have to guess your intent.
Self-reviewed first. Read your own diff before asking others. You will catch half the issues yourself, and your reviewer will notice the care.

6Quick check

Q. A reviewer asked for a change on your open PR. You should...

The PR watches your branch, not a frozen snapshot. Any new commit you push to that branch appears in the PR instantly, with the whole conversation intact. Closing and opening a new PR strands that discussion on the old, closed one, so the review starts over from scratch, and changing main directly skips review entirely.

Head scratcher: why is it called a pull request when you pushed your branch?

It reads from the project's point of view. You pushed your branch up to GitHub, yes. But then you are requesting that they pull your work into main. You pushed the branch up; they pull it in.

🧠 If you remember one thing: a pull request is just branch + push + "please review, then merge it," and small, well described PRs get merged fast.