On a GitHub pull request, what is the difference between Approve, Request changes, and Comment?

## A review is an object, not a comment On GitHub, individual remarks on the diff are **review comments**, and a **review** is the container you submit them in, carrying one of three states: `APPROVED`, `CHANGES_REQUESTED`, or `COMMENTED`. (Two more states exist in the API: `PENDING` for a review you are still drafting, and `DISMISSED` for one that has been set aside.) Understanding that a review is a stateful object is what makes the rest of the behaviour predictable. ## The three verdicts **Approve** is a sign-off. If the repository requires a number of approving reviews before merging, yours counts toward it. Approving is not a claim that the code is perfect; it is a claim that you are content for it to merge, which is why approving while leaving non-blocking notes is normal and healthy. **Request changes** is an objection with teeth. It records that you, specifically, want something changed. It persists until one of two things happens: you submit a new review that approves, or someone with write access **dismisses** it with a stated reason. Notably, pushing new commits does not automatically clear it — the author fixing the problem does not retract your objection, and re-requesting your review is the normal next step. **Comment** submits your remarks with no verdict. Use it for questions, for context, for a partial review ("I looked at the migration only"), and for the case where you have opinions but no objection. It neither blocks nor unblocks anything. ## Blocking is a repository policy, not a property of the button The frequent misconception is that Request changes freezes the pull request. What it does on its own is make the objection loudly visible. The **merge** is blocked only when the repository has a rule requiring approving reviews — then an outstanding changes-requested review from an eligible reviewer prevents the merge until it is resolved. In an unprotected repository, a colleague with write access can merge straight over your objection. The button is a signal; the rule is the enforcement. Knowing which is which is what separates "I have used GitHub" from "I understand GitHub". ## Submitting: single comments versus a batched review There are two ways to leave a line comment. **Add single comment** posts immediately and notifies the author right away. **Start a review** puts your comments in a pending state visible only to you; they stay pending until you hit Submit review and choose a verdict, at which point they are delivered together as one notification. Batching is almost always the better behaviour. It spares the author fifteen separate notifications, it lets you revise or delete a comment when the next file explains what you were confused about, and it means the author sees the whole picture before starting to respond — rather than fixing your first three notes while you are still writing the one that says the approach should change. ## Reviewing your own pull request GitHub does not let an author approve or request changes on their own pull request; only Comment is available. This exists so required approvals mean something. Practically, authors should still use it: self-reviewing the diff before requesting review, and leaving comments that explain a non-obvious choice, measurably reduces round trips. ## Choosing a verdict well Approve when you are willing for it to merge, and say which of your remarks are optional. Request changes when something is genuinely wrong — a correctness bug, a security problem, a contract break — and say plainly what would satisfy you, because an objection without an exit condition is what makes review feel adversarial. Comment when you have questions, when the review is partial, or when the decision is not yours to gate. The verdict is also a social signal, and the two failure modes are symmetric: requesting changes over a naming preference teaches people that the state is noise, while approving code you believe is broken because you do not want conflict is how defects reach production with a green checkmark next to them.