Reviewing and Merging a Pull Request

A pull request is only as useful as the review that happens before the merge. This lesson covers how to read a diff on GitHub, leave meaningful feedback, and choose the right merge strategy.

Reading the Files Changed tab

The Files changed tab is the core of PR review. Each changed file shows a unified diff — the same format as git diff, rendered with syntax highlighting.

• Green lines (with +) — additions
• Red lines (with -) — deletions
• White lines — unchanged context

The diff shows three lines of context around each change by default. Click the expand arrows between diff hunks to see more of the file.

Use Split or Unified view (the toggle in the top right of the diff) based on your preference. Split shows old and new side by side; unified shows them interleaved.

Leaving inline comments

To comment on a specific line:

1. Hover over the line number — a + icon appears
2. Click it to open a comment box
3. Write your comment and click Add single comment (to post immediately) or Start a review (to batch comments and post them together)

Use Start a review when you have multiple comments — it lets the author receive them all at once rather than notification by notification.

Good inline comments:

• Ask questions rather than demanding (“Was this intentional?” rather than “This is wrong”)
• Suggest specific alternatives when you spot an issue
• Acknowledge good work (“Nice — this is much cleaner than before”)
• Distinguish blocking issues from suggestions (“nit:” for minor style preferences that do not block approval)

Submitting a review

After leaving inline comments, click Review changes (top right of the Files changed tab):

• Comment — Leave feedback without explicitly approving or requesting changes. Used for minor notes.
• Approve — Signals the PR is ready to merge. Most teams require at least one approval.
• Request changes — Blocks the PR from merging until the author addresses your feedback and re-requests review.

Merge strategies

GitHub offers three ways to merge a pull request. The right choice depends on your team’s preferences and the branch history.

Merge commit (default)

main: A - B - C - M
                  ↑ merge commit
feature:    D - E

Creates a merge commit that joins the two branches. The feature branch commits remain in history as-is. The branch structure is visible in git log --graph.

Use when: you want to preserve the exact commit history of the feature branch, including intermediate commits.

Squash and merge

All commits on the feature branch are squashed into one commit on main:

main: A - B - C - D'
                  ↑ squashed commit (combines D + E + any others)

The feature branch commits disappear from main’s history; only the squashed result remains.

Use when: your feature branch has messy intermediate commits (“WIP”, “fix typo”, “oops”) that you do not want cluttering main’s history. Write a clean squash commit message.

Rebase and merge

The feature branch commits are replayed on top of main, one by one, with new hashes:

main: A - B - C - D'' - E''
                  ↑ rebased commits (new hashes, no merge commit)

Linear history — no merge commit.

Use when: your team values a clean linear history and each feature branch commit is meaningful and well-described on its own.

After you choose — clicking the merge button

1. Select your merge strategy from the dropdown arrow next to Merge pull request
2. Review the commit message (especially for squash — edit it to be descriptive)
3. Click Confirm merge

The branch is merged into main. GitHub shows a Delete branch button — click it to clean up the remote branch.

Syncing your local main after a merge

After merging on GitHub, your local main is behind:

git switch main
git pull

If you are done with the feature branch locally:

git branch -d feature/trail-difficulty

Exercise

1. Go to the open pull request from the previous lesson (feature/trail-difficulty → main).

2. Open the Files changed tab. Read the diff.

3. Leave an inline comment on any line. Post it.

4. Click Review changes → Approve → Submit review (since this is your own PR, self-approval is fine for practice).

5. Merge the PR using Squash and merge. Edit the squash commit message to be descriptive.

6. Click Delete branch to remove the remote branch.

7. In your terminal, sync local main and delete the local branch:

git switch main
git pull
git branch -d feature/trail-difficulty

8. Run git log --oneline and confirm the squashed commit appears on main.

Recap

• The Files changed tab shows the unified diff. Green = additions, red = deletions.
• Inline comments let you give specific, line-level feedback.
• Three merge strategies: merge commit (preserves branch history), squash and merge (one clean commit), rebase and merge (linear history, no merge commit).
• After merging on GitHub, pull locally to sync main, then delete the local branch.

Next: handling merge conflicts in a pull request — what causes them and how to resolve them before merging.