# What is a pull request? Anatomy of a PR page > What a pull request is, read top to bottom: base and compare branches, draft and ready, the four tabs, the description and a pull request template, reviewers and labels, linked issues, checks and the merge box. - Course: [Git and GitHub for Product People](https://productovi.com/courses/git-for-product.md) - Module: Pull requests - Lesson 7/15, ~40 min - Source: https://productovi.com/courses/git-for-product/pull-request-anatomy ## What is a pull request? Ready for review **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, from CatChow's product team. **Sofia:** 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:** Same thing, different name: GitLab calls it a **merge request**, MR for short. Pull request vs merge request is only a naming difference. GitHub names it after pulling the changes in, GitLab after the merge itself. ![A pull request page: the header with the merge direction, four tabs, the description, the merge box at the bottom, and a sidebar with reviewers, labels and the linked issue.](https://productovi.com/courses/git-for-product/diagrams/m3-l1-pr-page-map.png) ```text 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 ``` **Sofia:** 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`. ![A small boat waits in a canal lock between a narrow side canal and the wide main canal while a lock keeper with a clipboard checks it.](https://productovi.com/courses/git-for-product/inline/pull-request-anatomy-illustration-2.webp) *Read the direction first: which branch the work comes from, and where it goes.* **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. > **Exercise:** 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? ## Draft pull request or ready for review **Sofia:** 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. **Sofia:** So draft or open, neither one is merged. The badge says whether the author wants reviews yet. > **Exercise:** Pull request #136 shows this badge. If a reviewer approves it now, the author can merge it straight away. ## The four tabs of a pull request **Alex Tutor:** Under the header there are four tabs, as of 2026: `Conversation`, `Commits`, `Checks` and `Files changed`. Each shows a counter. **Alex Tutor:** `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. **Alex Tutor:** `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. ```text Commit graph, oldest first: What the Commits tab of #134 covers 1. commit f02a6d4 on main "Update FAQ answers" 2. branch fix/checkout-button starts from commit f02a6d4 3. commit 3a9d1c4 on fix/checkout-button "Reproduce bug in a test" (highlighted) 4. commit 8be2f70 on main "Add cat treats bundle" 5. commit b7e4a05 on fix/checkout-button "Re-enable button after cart edits" (highlighted) 6. commit 6f2c8a1 on main "Raise free-delivery threshold to 1000 UAH (#133)" 7. commit a7d93e4 on main "Rewrite delivery page copy (#132)" ``` *The 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.* **Alex Tutor:** `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. > **`Files changed` on #134** > > ```text > 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. **Sofia:** 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. > **Exercise:** You want to answer four questions about #134. Match each question with the tab where you'll find the answer. ## How to write a pull request description **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. > **The description of #134** > > ```markdown > ## 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). > ``` **Sofia:** 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. ![A clipboard holds a short brief in four blank sections, each marked by a small icon: a pencil, a target, a checklist tick and a photo frame.](https://productovi.com/courses/git-for-product/inline/pull-request-anatomy-illustration-3.webp) *What, why, how to test, and what it looks like.* **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. > **Exercise:** Which of these belong in a good pull request description? Select all that apply. **Alex Tutor:** Quick check before the template. Two pull requests, side by side. > **Exercise:** Two pull requests land in your review queue. Which one can you review without asking the author a single question? ## A pull request template **Alex Tutor:** A **pull request template** is a Markdown file the team keeps in the repository, usually `.github/pull_request_template.md`. When anyone opens a new pull request, GitHub puts it into the description, so every PR starts from the same four headings instead of an empty box. > **CatChow's `.github/pull_request_template.md`** > > ```markdown > ## What > > > ## Why > > > ## How to test > 1. > > ## Screenshots > > ``` > The `` lines are hints for the author: GitHub doesn't show them in the finished description. **Daniel:** Ours came after one too many "pls review" descriptions. It takes two minutes to fill in, and the empty headings remind you what reviewers will ask. GitLab has the same idea: merge request templates. ## Fixes #131 **Sofia:** 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. **Alex Tutor:** 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. **Sofia:** 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. > **Exercise:** Pull request #134 says `Fixes #131` and targets `main`, the default branch. When does GitHub close issue #131? **Alex Tutor:** Daniel's catch deserves a check of its own. True or false? > **Exercise:** The pull request from Emma, CatChow's content marketer, goes into `feature/gift-wrap`, not `main`. Its description says `Closes #140`. When it's merged, GitHub closes issue #140. ## Who does what: the sidebar **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. **Alex Tutor:** `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. **Sofia:** 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. > **Exercise:** The sidebar of #134 shows: `Reviewers` Oscar and Sofia, `Assignees` Daniel, `Labels` `bug` and `checkout`, and under `Development` issue #131. CatChow's rules on `main` require one approval. Which statements are true? Select all that apply. ## Checks and the merge box **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`. ```text Checks on the latest commit of #134 - [All checks have passed] build: Successful in 1m - [All checks have passed] test: Successful in 3m - [All checks have passed] 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. ![Three small friendly robots stand along a conveyor belt inspecting a passing parcel, each holding up a green light.](https://productovi.com/courses/git-for-product/inline/pull-request-anatomy-illustration-4.webp) **Sofia:** 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. **Alex Tutor:** 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. > **Exercise:** Daniel pushes one more commit to `fix/checkout-button`, and the checks now look like this. What does it tell you? ## Explain it to support **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?" **Sofia:** 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. > **Exercise:** 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. ## Rewrite a weak description **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". **Sofia:** 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. > **Exercise:** Rewrite the description of pull request #149 so that a reviewer knows what changed, why, how to check it and what to decide. **Alex Tutor:** Tomorrow you review #134 for real: the preview, the copy and that stylesheet. **Sofia:** Four tabs, one question: does it do what #131 asked, and nothing else? - Previous lesson: [Merge conflicts on GitHub: why they happen and what to do](https://productovi.com/courses/git-for-product/merge-conflicts.md) - Next lesson: [Approve a pull request as a PM: comments and suggestions](https://productovi.com/courses/git-for-product/reviewing-as-a-pm.md) --- Productovi Learning. Free, no sign-up needed to read.