# Approve a pull request as a PM: comments and suggestions

> What a product person checks in a pull request and what to leave to engineers, how to comment on a line, suggest changes with the exact wording, decide when to approve a pull request or request changes, and write review comments people are glad to get.

- Course: [Git and GitHub for Product People](https://productovi.com/courses/git-for-product.md)
- Module: Pull requests
- Lesson 8/15, ~42 min
- Source: https://productovi.com/courses/git-for-product/reviewing-as-a-pm

## What a PM reviews in a pull request

**Alex Tutor:** Review day for #134, and you're the product team's reviewer at CatChow. By tonight you'll either approve the pull request or request changes. Before you open a single file: what exactly are you reviewing for?

**Sofia:** Not the code. The behaviour, I guess?

**Alex Tutor:** The change as a customer will meet it. Does it do what the issue asked? Does the copy read right? Does it do anything the issue didn't ask for? What happens in the cases nobody wrote down?

![A woman tries a shop checkout on her phone like a customer; behind her, a developer opens a panel and inspects the gears inside the machine.](https://productovi.com/courses/git-for-product/inline/reviewing-as-a-pm-illustration-2.webp)

**Daniel:** And leave the code to engineers: naming, structure, performance, which pattern I should have used. Oscar has that covered. He approved an hour ago.

```text
Reviews on #134 so far
- [Approved] Oscar: Approved these changes: the code is fine
```

**Sofia:** So my review answers "is this the right change for customers?", not "is this good code?"

**Alex Tutor:** Exactly. And if something in the code does look odd to you, ask a question. Don't give instructions about things you can't judge. Our post on [how to review a pull request](/blog/how-to-review-a-pull-request) keeps the whole checklist on one page.

> **Exercise:** Pull request #134 fixes issue #131: the checkout button stays grey after a customer edits the cart. Oscar reviews the code; Sofia is the product reviewer. Which of these belong in Sofia's review? Select all that apply.

## Start with the preview

**Alex Tutor:** Start where customers will: on the preview. Follow Daniel's "How to test" first, then try what he didn't write down.

**Sofia:** Steps one to three work on my phone. I change quantities, the button stays green. I remove everything, it turns grey with a hint: "Cart is empty. Add items to checkout."

**Alex Tutor:** Now the **edge cases**: the paths off the happy route. What else can a customer do to a cart?

![A wide road leads to a shop with narrow side paths and detours along it; a person with a flashlight explores one of the side paths.](https://productovi.com/courses/git-for-product/inline/reviewing-as-a-pm-illustration-3.webp)

*Customers rarely follow the exact steps in the description.*

**Sofia:** Remove items one by one with the minus button instead of the bin. Apply a promo code, then change a quantity. Open the cart in two tabs and edit it in both.

**Daniel:** The two tabs one is evil. I love it.

**Sofia:** All of them work. Only the hint bothers me: "Add items to checkout" reads like an error message.

> **Exercise:** #134 fixes the checkout button after cart edits. Daniel's “How to test” steps: change a quantity (the button stays green), then empty the cart (it turns grey with a hint). Which of these is an edge case worth trying on the preview, beyond those steps?

## Pull request comments on a line

**Alex Tutor:** Now `Files changed`. You don't have to read every file. As of 2026 each file has a `Viewed` checkbox: tick the ones you've looked at or left to others, and they fold away.

**Sofia:** The component and the test are Oscar's. That leaves `copy/cart.json` and `styles/checkout.css`.

**Alex Tutor:** Hover over a line in the diff, and a blue `+` appears. Click it, or drag across several lines, and a comment box opens right under the line.

**Alex Tutor:** The box has two buttons. `Add single comment` posts right away. `Start a review` keeps the comment as pending, so you can add more and send them all together with a verdict.

**Daniel:** Please batch. Five single comments are five pings in the middle of my work. One review is one ping with your whole thought in it.

**Alex Tutor:** Until you submit, the comments are marked `Pending`, and only you can see them.

> **Exercise:** Sofia starts a review and leaves three comments, each marked `Pending`. Daniel can already read them.

## Suggested changes: propose the exact words

> **`copy/cart.json` in #134**
>
> ```diff
>    "cartTitle": "Your cart",
> +  "checkoutDisabledHint": "Cart is empty. Add items to checkout.",
>    "promoCodeLabel": "Promo code"
> ```
> One added line: the hint shown under the grey button.

**Sofia:** Also, "checkout" is the noun, "check out" the verb. So it's wrong as well as cold.

**Alex Tutor:** Then don't describe the fix, write it. The comment toolbar has a button for a **suggested change** (as of 2026, a small icon with a plus and a minus). It inserts a `suggestion` block with the current line, ready to edit.

> **Sofia's comment on that line**
>
> ````markdown
> ```suggestion
>   "checkoutDisabledHint": "Your cart is empty. Add a treat to check out.",
> ```
> "Check out" is the verb here. A friendlier tone, too.
> ````

**Daniel:** On my side it shows as a mini-diff with a `Commit suggestion` button. One click, and your line becomes a commit on my branch, with you credited as co-author.

**Alex Tutor:** Keep suggestions for small, exact fixes: copy, a number, a link. For anything bigger, describe the problem and let the author pick the solution.

> **Exercise:** Put Sofia's steps for suggesting new wording in order.

**Alex Tutor:** Suggestions are handy, but not for everything. Which of these would you write as one?

> **Exercise:** Which of these is a good fit for a suggested change?

## The orange button

> **`styles/checkout.css` in #134**
>
> ```diff
>  .checkout-button {
> -  background: #2e9e5b;
> +  background: #f28c28;
>    border-radius: 8px;
> ```
> `#2e9e5b` is the current green; `#f28c28` is orange.

**Sofia:** Green to orange. Issue #131 says nothing about colour, and neither does the description.

**Daniel:** Guilty again. I was in that file anyway, and orange pops more. Admit it.

**Alex Tutor:** Maybe it does. But it's the main button of the whole shop, changed for every customer, inside a bug fix nobody will read as a redesign. If orders drop next week, nobody will know where to look.

**Sofia:** And it deserves a proper test: orange against green, as an A/B test, with its own issue.

**Alex Tutor:** That's the **scope** check: compare the diff with the issue and the description. Anything extra gets a question, never a silent approval.

![A reviewer opens a parcel and finds the ordered item plus an unexpected orange extra, holding it up with a curious look.](https://productovi.com/courses/git-for-product/inline/reviewing-as-a-pm-illustration-4.webp)

> **Exercise:** #134 fixes issue #131, the checkout button that stays grey after cart edits. Its diff also changes `styles/checkout.css`: the checkout button turns from green to orange. Neither the issue nor the description mentions colour. Why shouldn't the colour change ship inside #134?

## Tone: how to write review comments

**Alex Tutor:** Now write the comment on that line. Remember who reads it: a colleague who spent three days on this and will read your review at six in the evening.

**Alex Tutor:** A few habits help. Comment on the change, not the person. Say why, not only what. Ask when you're unsure. Mark small things as optional. And say what's good.

**Daniel:** "Why did you do this?" and "What's the reason for the colour change?" ask the same thing. Only one of them sounds like an interrogation.

**Sofia:** So: "The colour change isn't part of #131, and it affects every customer. Could we move it to its own issue and test it there?"

**Alex Tutor:** That's the one. Specific, with a reason and a way forward.

> **Exercise:** Which of these review comments would the author be glad to get and able to act on? Select all that apply.

## Comment, Approve or Request changes

**Alex Tutor:** Your comments are pending. To send them, use the review button at the top of `Files changed`: as of 2026 it says `Submit review` (older layouts say `Review changes`). It opens a box for a summary and three options.

**Alex Tutor:** `Comment`: feedback without a verdict. `Approve`: this can be merged. `Request changes`: something must change before it's merged.

**Daniel:** People also write "LGTM" in approvals: "looks good to me". Fine, as long as it's true. The rudest review is an LGTM on a pull request nobody opened.

**Sofia:** And `Start a review` versus `Add single comment`? Where does that fit?

**Alex Tutor:** That comes earlier in the flow. Those two decide whether a comment waits for your verdict or goes out alone. The verdict itself is always one of these three.

![A PM review goes preview, then Files changed for copy and scope, then pending line comments, and ends with one verdict: comment, approve or request changes.](https://productovi.com/courses/git-for-product/diagrams/m3-l2-pm-review-flow.png)

> **Exercise:** Match each situation with the button or option Sofia should use.

**Sofia:** The copy is a small fix, but the colour is a real blocker for me. So: `Request changes`?

**Alex Tutor:** Yes, as long as the summary says exactly what blocks and why. Don't request changes over a comma, and don't approve while hoping someone else catches the colour.

**Daniel:** `Request changes` isn't rude. It's precise. I'd rather know what blocks the merge than guess from a pile of comments.

**Alex Tutor:** Before you write it, try the same choice on a calmer pull request.

> **Exercise:** Another pull request: the preview works in every case you tried, and the only note you have is an optional, friendlier wording for a tooltip. Which review do you send?

**Alex Tutor:** Write the summary now. It's the first thing Daniel reads, above your line comments.

> **Exercise:** Write the summary for Sofia's `Request changes` review of #134 (2–4 sentences). Her line comments: a suggestion for the hint copy in `copy/cart.json`, and a note that the colour change in `styles/checkout.css` isn't part of #131. The preview worked in every case she tried.

## The rules on main

**Alex Tutor:** You press `Submit review`. The merge box at the bottom of `Conversation` now says "Changes requested", and the merge is blocked, even though Oscar approved.

```text
Reviews on #134 after Sofia submits
- [Approved] Oscar: Approved these changes
- [Changes requested] Sofia: Requested changes: colour change is outside #131
```

**Sofia:** Wait, my review blocks it? Daniel said one approval is enough.

**Daniel:** One approval is required, and a request for changes from anyone with write access holds the merge until that person approves or the review is dismissed. That's our **branch protection** on `main`.

**Alex Tutor:** Branch protection, or a ruleset in newer settings, is a list of rules GitHub enforces on a branch. On `main` at CatChow: changes only through pull requests, at least one approval, `build` and `test` must pass, every conversation resolved, and the branch up to date with `main`.

**Daniel:** The last rule appeared after my March adventure with the cookie bar. You'll see it in action tomorrow.

**Sofia:** And Daniel can't just approve his own pull request?

**Daniel:** No. GitHub doesn't let authors approve their own pull requests, and only reviews from people with write access count towards the rule.

> **Exercise:** CatChow's rules on `main` require one approval, and both Oscar and Sofia have write access. The checks have passed. Can Daniel merge #134 right now?

## Fix, resolve, approve

**Alex Tutor:** An hour later. Daniel clicked `Commit suggestion` on the hint, put the green back in a second commit and replied to both of your comments.

```text
Commit graph, oldest first: fix/checkout-button after the review
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"
4. commit 8be2f70 on main "Add cat treats bundle"
5. commit b7e4a05 on fix/checkout-button "Re-enable button after cart edits"
6. commit 6f2c8a1 on main "Raise free-delivery threshold to 1000 UAH (#133)"
7. commit a7d93e4 on main "Rewrite delivery page copy (#132)"
8. commit c2d7f90 on fix/checkout-button "Update checkout hint copy" (highlighted)
9. commit f7a2b61 on fix/checkout-button "Restore checkout button colour" (highlighted)
```

*Two new commits on the branch: c2d7f90 applies Sofia's suggestion, f7a2b61 restores the green button. main hasn't changed.*

**Daniel:** I typed the message for your suggestion myself: "Update checkout hint copy". GitHub lists you as co-author on that commit. Your first line of code, sort of.

**Sofia:** His reply under the colour: "Fair. Orange moved to #135, let's test it properly." And he clicked the arrows next to my name to re-request my review.

**Alex Tutor:** Now close the loop. Each comment thread has a `Resolve conversation` button, and CatChow's rules block the merge while any thread is open. Here, whoever opened a thread resolves it once satisfied.

**Sofia:** My line is in, the green is back. Resolving both threads, and this time: `Approve`.

## Your own review

**Alex Tutor:** One more pull request for you, start to finish. #154, "Add gift note to checkout", answers issue #139: customers asked to add a note to orders they send as gifts. Oscar has approved the code; the rest is yours.

**Sofia:** Issue first, then the description, then the preview, then the diff.

**Alex Tutor:** Good order. Then write the review as you would send it: the line comments, a suggestion where it fits, and a verdict with a summary.

> **Exercise:** Write your review of pull request #154: line comments (with a suggestion where it fits), a verdict and a summary.

**Alex Tutor:** Next lesson: every icon and colour you've seen this week, and a few you haven't, read at a glance.

**Daniel:** And tomorrow morning I merge #134. Well, as soon as the merge box stops asking me for one more thing.

- Previous lesson: [What is a pull request? Anatomy of a PR page](https://productovi.com/courses/git-for-product/pull-request-anatomy.md)
- Next lesson: [Icons, colours and checks: what every GitHub state means](https://productovi.com/courses/git-for-product/icons-and-colours.md)

---
Productovi Learning. Free, no sign-up needed to read.