What is a pull request? A PR page explained for PMs

Alex Tutor

Remember #134, Daniel's checkout fix? This morning he pressed Ready for review and asked two people to review it. One of them is Oscar, our backend developer. The other one is you.

You

Me? Reviewing a code change? I can read a diff now, but I can't judge code.

Daniel

You don't have to. Oscar reviews the code. You check that the fix does what support asked for, and that customers see the right thing. But first, read the page from top to bottom.

Alex Tutor

A pull request is a proposal: "take the commits from my branch and merge them into that one". Its page collects everything needed to decide: the description, the discussion, the commits, the automated checks and the diff.

Alex Tutor

The header of pull request #134

Open
Fix checkout button after cart edits#134
Daniel wants to merge 2 commits into main from fix/checkout-button

You

The title, the number, a green Open badge, and a line underneath: "Daniel wants to merge 2 commits into main from fix/checkout-button".

Alex Tutor

That line holds the most important fact on the page: the direction. main is the base branch, where the changes will go. fix/checkout-button is the compare branch, where they come from. GitHub also draws it as main ← fix/checkout-button.

Daniel

The base isn't always main. Some pull requests go into another feature branch, and some teams merge into develop first. Always read the arrow before you celebrate.

Alex Tutor

Question 1

Another pull request's header reads: "wants to merge 3 commits into feature/gift-wrap from feature/gift-wrap-copy". It gets merged. Where do the three commits end up?

Choose one answerIn main, and so on the live siteIn feature/gift-wrap-copy, the branch they were written onIn feature/gift-wrap; main doesn't changeNowhere yet: a merge only takes effect after a release

You

Yesterday the badge was grey and said Draft. What changed, apart from the colour?

Alex Tutor

A draft pull request means "work in progress, don't review yet". GitHub won't merge a draft: where the merge button would be, there's a Ready for review button instead.

Daniel

I open drafts early on purpose. The team can see what I'm working on, the automated checks already run on every commit, and nobody wastes a review on half a fix.

Alex Tutor

It works backwards too. As of 2026, a small Convert to draft link in the sidebar sends an open pull request back to draft, for example when the author finds a problem mid-review.

You

So draft or open, neither one is merged. The badge says whether the author wants reviews yet.

Alex Tutor

Question 2

Pull request #136 shows this badge. If a reviewer approves it now, the author can merge it straight away.

Draft
Add autumn sale banner#136

TrueFalse

Alex Tutor

Under the header there are four tabs, as of 2026: Conversation, Commits, Checks and Files changed. Each shows a counter.

Conversation is the timeline: the description first, then comments, reviews, new commits and status changes in time order. At the bottom sits the merge box.

Commits lists the branch's commits, here two: 3a9d1c4 "Reproduce bug in a test" and b7e4a05 "Re-enable button after cart edits". Checks shows the automated runs with their logs.

Alex Tutor

What the Commits tab of #134 coversThe pull request contains only the two commits on fix/checkout-button. Meanwhile main has moved on by three commits; lesson 3 shows what that means for the merge.

f02a6d4Update FAQ answers
3a9d1c4Reproduce bug in a test
8be2f70Add cat treats bundle
b7e4a05Re-enable button after cart editsfix/checkout-button
6f2c8a1Raise free-delivery threshold to 1000 UAH (#133)
a7d93e4Rewrite delivery page copy (#132)main

Files changed is the diff of the whole pull request: every file it touches, removed lines in red, added lines in green, just as in module 1.

Alex Tutor

`Files changed` on #134

components/CheckoutButton.tsx        +9  −3
components/CheckoutButton.test.tsx  +24  −0
copy/cart.json                       +1  −0
styles/checkout.css                  +1  −1

Four files. The numbers show how many lines were added and removed in each.

You

The button, a test, the cart texts... and styles/checkout.css? Why does a bug fix change the styles?

Daniel

Good eye. Hold that question for your review tomorrow.

Alex Tutor

Question 3

You want to answer four questions about #134. Match each question with the tab where you'll find the answer.

Tap an answer, then tap the row it belongs to. You can also drag.

Did the automated tests pass, and what does the log say?
Which line was added to copy/cart.json?
What did Oscar write in his review?
In what order did Daniel make his changes, step by step?

Answers left to place

Alex Tutor

Back to Conversation. The first comment is the description Daniel wrote when he opened the pull request. For a reviewer it's the most useful text on the page.

Alex Tutor

The description of #134

## What
The checkout button stays active after a customer changes
quantities or removes items. When the cart is empty, the button
is disabled and a short hint explains why.

## Why
Fixes #131. After editing the cart, customers saw a grey button
and couldn't check out until they reloaded the page.

## How to test
1. Open the preview link and add two products to the cart.
2. Change the quantity of one of them: the button stays green.
3. Remove every item: the button turns grey and shows a hint.

## Screenshots
Before / after, cart page on a phone (two images).

You

What, why, how to test, screenshots. It reads like a mini brief.

Alex Tutor

That's the idea. What: the change in plain words. Why: the problem, linked to its issue. How to test: steps anyone can repeat. Screenshots: before and after, for anything customers see. Some teams add a fifth part: what is deliberately left out.

Daniel

A good description saves me a meeting. A weak one says "fixed checkout, pls review", and then three reviewers ask me the same three questions.

Alex Tutor

The title works the same way. "Fix checkout button after cart edits" says what changes and where. "Checkout fixes" or "Daniel's branch" says nothing in a list of fifty pull requests.

Alex Tutor

Question 4

Which of these belong in a good pull request description? Select all that apply.

Choose all that applyThe problem the change solves, with a link to its issueA list of every file the pull request changesSteps a reviewer can follow to check the result"Pls review asap"Before-and-after screenshots of a visible changeWhat the change deliberately leaves out

You

The "Why" part says "Fixes #131". Is that just a link?

Alex Tutor

More than a link. #131 is the issue support opened: "Checkout button stays grey after editing cart". Fixes is a closing keyword: when #134 is merged into the default branch, GitHub closes #131 on its own.

Close, fix and resolve all work, in any form: Closes #131, Fixed #131, Resolves #131. Without a keyword, "#131" is only a reference. Both pages mention each other, and nothing closes.

Daniel

The sidebar confirms it under Development. As of 2026 it says "Successfully merging this pull request may close these issues" and lists #131.

You

And since we deploy on every merge, support will see the issue close at about the time the fix goes live.

Daniel

Within minutes of it, yes. One catch: the keyword only works in pull requests into the default branch. Merge one into some other branch, and it closes nothing.

Alex Tutor

Question 5

Pull request #134 says Fixes #131 and targets main, the default branch. When does GitHub close issue #131?

Choose one answerAs soon as #134 is openedWhen the first reviewer approves #134When Daniel presses Ready for reviewWhen #134 is merged into main

Alex Tutor

On the right is the sidebar. Reviewers: people asked to review, here Oscar and you. Assignees: who is responsible for getting the pull request done, usually the author, so Daniel.

Labels: coloured tags for sorting and filtering, here bug and checkout. Projects and Milestone place the work in the team's plans; that's module 5. And Development holds the linked issue.

You

Why two reviewers? Isn't one enough?

Daniel

For GitHub, one is enough: our rules for main need one approval before a merge. Two is our team habit. An engineer approves the code, and anything customers will see also gets a product review.

Alex Tutor

Keep that difference in mind. A rule is enforced by GitHub: the merge button simply stays blocked. A habit is enforced by the team. You'll see where the rules live in the next lesson.

Alex Tutor

Question 6

Which statements about the sidebar of #134 are true? Select all that apply.

Choose all that applyDaniel is the assignee, so his own changes count as approvedOscar and Sofia are under Reviewers because Daniel asked them to reviewRemoving the checkout label would block the mergeThe bug label helps sorting and filtering; it doesn't change the codeDevelopment shows #131, the issue that merging #134 will close

Alex Tutor

Every time Daniel pushes a commit, checks run automatically. CatChow has three: build (does the site still build?), test (do the automated tests pass?) and preview.

Alex Tutor

Checks on the latest commit of #134

build
Successful in 1m
test
Successful in 3m
preview
Preview deployed: View deployment

Daniel

build and test are continuous integration, CI for short: robots checking every change. And preview is the one for you. It deploys this branch to a temporary copy of the site with its own link.

You

So I can click through the fix on my phone before a single customer sees it. That's the preview link in "How to test".

Alex Tutor

Exactly. Now scroll to the bottom of Conversation. The merge box sums up whether the pull request can be merged: reviews, checks and conflicts.

Right now it says "Review required" and "Merging is blocked", GitHub's wording as of 2026. The checks are green, but nobody has approved yet. Lesson 3 goes through every message it can show.

Alex Tutor

Question 7

Daniel pushes one more commit to fix/checkout-button, and the checks now look like this. What does it tell you?

Checks on the newest commit

build
test
preview

Choose one answerThe live site is broken and customers can't check outAn automated test failed on the new commit; it needs fixing before the mergeThe preview failed, so there is nothing to click throughAll is well: red just marks the check that ran last

Alex Tutor

Support noticed a link to #134 on their issue and asks you: "It says 'Fixes #131'. Does that mean the button is fixed?"

You

Not yet. The pull request is open, not merged.

Alex Tutor

Answer them in two or three sentences: what the line means, what has to happen first and how they'll know it's done.

Daniel

And no dates, please. It still has to pass review.

Alex Tutor

Question 8Short answer · AI-checked task

Support asks: "Pull request #134 says 'Fixes #131'. Does that mean the checkout button is fixed?" #134 is open, waiting for review, and CatChow deploys every merge into main within minutes. Write a 2–3 sentence answer without Git jargon.

Write your answer and get a score with feedback from our AI reviewer.

Log in to get AI feedback

Alex Tutor

One more pull request in your queue. A colleague opened #149, "product page fixes". The entire description reads: "fixed some stuff, pls review".

You

I can't even tell what I'm supposed to test.

Daniel

I've written that exact description myself. On a Friday evening. Nobody touched the pull request until Tuesday.

Alex Tutor

Look at what the tabs show and which issue it answers. Then rewrite the description under the four headings, and flag anything the reviewers need to decide.

Alex Tutor

Question 9Case · AI-checked task

Rewrite the description of pull request #149 so that a reviewer knows what changed, why, how to check it and what to decide.

Pull request #149 "product page fixes", main ← fix/product-page. Description: "fixed some stuff, pls review".

What the tabs show:

The issue it answers: #143 "Product cards round prices up", opened by support; the pull request doesn't mention it. Cards show 250 UAH, the cart charges 249.99 UAH, and customers ask which price is right.
components/ProductCard.tsx: cards now show the exact price, 249.99 UAH instead of 250 UAH.
components/ProductCard.test.tsx: a new test for price formatting.
copy/product.json: the label on out-of-stock products changes from "Sold out" to "Back soon".
Checks: build, test and preview passed; the preview link works.

Write the new description with What, Why, How to test and Screenshots. Point out anything reviewers need to decide on.

Write your answer and get a score with feedback from our AI reviewer.

Log in to get AI feedback

Tomorrow you review #134 for real: the preview, the copy and that stylesheet.

You

Four tabs, one question: does it do what #131 asked, and nothing else?

Alex Tutor

That’s the lesson. You answered every task — nicely done.

Next lesson: Reviewing as a PM: comments, suggestions, approve