Review a pull request

A useful review checks whether a proposed change does what it promises and gives the author clear next steps. This guide shows you how to inspect a website pull request on GitHub, check its behavior, and submit feedback that distinguishes a required fix from a suggestion.

Before you start

• A GitHub account signed in at GitHub.com, read access to the repository, and the URL of an open pull request.
• The project’s contribution and review instructions, including the behavior the change is meant to deliver.
• For hands-on testing, an approved preview of this exact revision or a local copy checked out to the pull request branch, plus the project’s setup instructions and test data. Ask the author for help if you cannot run it.
• Time to inspect the entire change. You can comment on your own request, but GitHub does not let authors approve their own pull requests.

Want to do it yourself?

Difficulty

8 out of 10

Estimated completion time

45–120 minutes per small pull request

Skills you’ll need: Read the affected code, test the promised behavior and edge cases, and tie useful feedback to specific lines.

I’ll do it myselfI’d rather get help

How this helps your brand

Evidence-based review helps catch changes that could confuse customers or interrupt a working flow. Separating reproduced defects from suggestions gives the author a practical route to a dependable release.

1. 1

   Step 1: Read the goal and diff

   Open the request and read the description, relevant discussion, and linked issue. Write down what should change and what should keep working. For example: “An empty newsletter submission shows a message; a valid email can still subscribe.” If the goal is unclear, ask the author before judging whether the code meets it.

   Open Files changed and scan the complete file list. The diff shows additions and removals. Inspect each file and follow the affected behavior into the surrounding code where needed. For the newsletter example, a change in the form may also depend on server validation and how a failed response is displayed.

   Check whether the description accounts for changes to configuration, dependencies, or stored data. If part of the change is outside your expertise, say which part needs another reviewer. Keep notes with file names and line numbers so you can return to the evidence.

   Tip: An author’s explanation is a starting point. Compare it with what changed, and ask a specific question about anything you cannot connect to the stated goal.

   Illustrated exampleFollow the promise beyond the changed file

   PR #42 · promised behaviorRequire an email before accepting a booking.

   1. 1
      BookingForm.tsxCustomer enters an email

      The changed field shows an error when left empty.

      Changed
   2. 2
      api/bookings.tsServer checks the request

      Follow this call too. A request can skip the form.

      Surrounding code
   3. 3
      saveBooking()Only valid bookings reach storage

      Check what happens before the record is created.

      Surrounding code

   A changed-file list is the starting point. Trace the behavior across the code it calls.

2. 2

   Step 2: Check concrete risks

   Use a preview confirmed to match the request’s current revision, or check out the pull request locally using the project’s process. A preview is only available if the project provides one. Follow its setup instructions and use test accounts or data. If you cannot run the change, record that limitation and request the evidence you need.

   Repeat one normal path and one meaningful failure or boundary case. In the newsletter example, submit a valid test email, then an empty value. Compare what happens with what the request promises. Check whether the error is visible, whether keyboard users can reach the controls, and whether the existing success path still works.

   Look at automated check results and their details when configured. Record what actually ran and any failures, alongside your own observations. If the preview shows different behavior from the code you read, stop and confirm its revision with the author before reporting a bug.

   • For each case, write down the input, expected result, actual result, and environment.
   • Separate a reproduced defect from a question or an untested concern.
   • If a required check is failing or important evidence is missing, explain what must be investigated before you can recommend approval.

   Tip: “All checks passed” is evidence about those checks. It does not establish that every visitor action, device, or failure state was tested.

   Illustrated examplePair a normal path with a boundary case

   Example review notes · POST /api/bookings

   Case	Expected	Observed
   Normal pathEmail: [email protected]	Booking saved	Pass201 · created
   Edge caseEmail omitted from a direct request	400 · validation error; no booking saved	Required fix201 · empty email saved

   ↳

   The form catches it. The server still accepts it. Reproduce the direct request and check storage before writing the finding.

3. 3

   Step 3: Leave useful feedback

   For a specific problem, hover over the relevant changed line, use the comment icon, and choose Start a review. Add further findings with Add review comment. Pending review comments are only visible to you until you submit the review.

   Explain the trigger, impact, and a way to verify a fix. For example: “Required fix: submitting an empty email still shows success. A visitor may think they subscribed. Please reject the submission and show an error; recheck both empty and valid input.” Use this wording only if you observed that behavior. Label an optional improvement as a suggestion and explain its value.

   Open Review changes, or Submit review if a pending review is already open, and add a summary using the template below. Choose Comment when leaving feedback without a decision, Approve when your review supports merging, or Request changes for work that needs correction. Then submit the review and confirm it appears in the conversation.

   If you are uncertain about an important area, describe the gap and use Comment while seeking help. Whether a requested change blocks merging depends on repository rules and reviewer permissions. When the author posts a revision, recheck the affected behavior and any new changes before submitting a follow-up decision.

   Tip: Check the conversation after submitting so your notes are not left pending. Approval records your review decision; it does not perform the merge.

   Illustrated exampleMake the finding easy to reproduce and verify

   api/bookings.tsIllustrative diff

   18const body = await request.json();

   19await saveBooking(body);Review here

   Required fixReject a missing email on the server

   Trigger

   POST a booking directly without an email.

   Impact

   The server returns 201 and stores a booking we cannot confirm by email.

   Verify

   Expect 400 and no new record. A valid email should still create a booking.

   Optional suggestion Shorten the field label to “Email”. Keep this separate from the required validation fix.

   ↻ After revisions, rerun both cases before approving.

Review of: [pull request number and revision or commit reviewed]

Goal checked: [the promised behavior]
Scope reviewed: [files and affected flow; name anything needing another reviewer]

Checks I ran: [commands or manual steps, environment, expected and actual results]
Normal case: [input and observed result, or not tested with reason]
Failure case: [input and observed result, or not tested with reason]
Automated checks: [relevant reported results, or not configured or not inspected]

Required fixes: [for each verified issue: file and line, trigger, impact, and how to verify the fix; write none found if applicable]
Optional suggestions: [improvements that need not block this change, or none]
Open questions and limits: [missing context or tests, or none]

Review decision: [Comment, Approve, or Request changes, with a short reason based on the evidence]