Pull Requests
A pull request (PR) is GitHub's mechanism for proposing changes and getting them reviewed before they land in the main branch. Everything covered in Chapters 4 and 5 — branching, pushing — leads here: a PR is what turns "I pushed a branch" into "this change is reviewed, discussed, and ready to merge."
What a Pull Request Actually Is
Despite the name, a pull request isn't really about "pulling" anything technically new — it's a request asking the maintainers of a repository to merge your branch into another branch (almost always into master or main). It wraps that merge in a conversation: a description, a diff view, comment threads, and a record of who approved it and when.
git merge — the PR just adds the review and discussion layer on top.
Making Your First Pull Request
git switch -c fix/typo-homepage, edit, commit — exactly the workflow from Chapter 4.git push -u origin fix/typo-homepage — the branch now exists on GitHub, but nothing has been merged yet.Description
Fixes "Welcom" → "Welcome" in the hero heading on the homepage. Spotted while reviewing the live site.
Reading and Responding to Review Comments
Reviewers can comment on the PR as a whole, or on specific lines of the diff. Line-level comments are the most useful — they let a reviewer point at exactly the code they're talking about.
MAX_RETRIES.
Responding to feedback the right way
- Push new commits to the same branch — they automatically appear in the same open PR. No need to close and reopen anything.
- Reply directly under the relevant comment rather than a general reply, so the conversation stays attached to the specific code it's about.
- Mark resolved threads as resolved once addressed — keeps the PR readable for anyone reviewing later, including the eventual approver.
- Disagreeing is fine — explain your reasoning rather than silently ignoring or silently complying with feedback you think is wrong. The discussion thread exists precisely for this.
Merging the Pull Request
Once a PR is approved (or, on a solo project, once you're satisfied with it yourself), GitHub offers three merge strategies — the choice affects what your history looks like afterward, covered in depth in Course 2's branching strategies chapter:
- Merge commit — preserves every individual commit from the branch, plus a new merge commit tying them together. Most information-preserving, but can clutter history with many small commits.
- Squash and merge — combines all commits on the branch into a single commit on the target branch. Clean history, but loses the individual commit-by-commit story.
- Rebase and merge — replays the branch's commits individually onto the target branch with no merge commit at all. Clean and linear, but rewrites commit hashes (relevant once Course 3 covers rebasing in depth).
$ git switch master
$ git pull
# Brings the merged change down to your local master
$ git branch -d fix/typo-homepage
# Delete the now-merged local branch (Chapter 4)
git branch -d. Harmless to leave around, but tidying up keeps your branch list from accumulating clutter over time.
Chapter 7 Quick Reference
- A PR is GitHub's review/discussion layer on top of an ordinary git merge — not a git feature itself
- Flow: branch → push → open PR → write a clear title/description → (request review) → merge
- Pushing new commits to the branch updates the same open PR automatically
- Reply to specific line comments rather than general replies, to keep feedback attached to the relevant code
- Three merge strategies: Merge commit (preserves all), Squash (one clean commit), Rebase (linear, no merge commit)
- After merging: pull on your local master, then delete your local branch — GitHub's "Delete branch" only removes the remote copy
- Next chapter: undoing mistakes — restore, soft reset, revert vs reset, and amend