Pull requests — propose, don't just ship

Your branch is pushed. It’s up on GitHub now — but off to the side. The real project (main) still doesn’t have your changes. You could just merge your branch straight in. On any project with other people, you don’t. You open a pull request.

A pull request (PR) says “here’s my change — look it over before it goes into the real project.” It turns a change into a proposal with a conversation around it.

The name is a little backwards: you’re requesting that the project pull your branch in. What it actually is, in practice, is a page on GitHub that shows your changes (the diff), a description you write explaining them, and a space for other people to comment — all before anything merges into main.

The difference from just merging it yourself: a PR adds a deliberate pause for review, and a permanent record of why the change happened.

The description is the “why” for the whole change

Your commit messages (from Lesson 8.3) explain each individual step. The PR description zooms out: it explains the whole change at once — what it does, why it was needed, and anything a reviewer should know before they look.

Claude writes these well. Point it at your branch and it reads every commit, then summarizes them into a clean write-up. Your job is the same as with a commit message: check that it’s honest and complete before it goes out. You’re the one who knows whether it’s actually ready.

The Claude way

With the gh tool set up (that’s GitHub’s command-line helper), Claude does the whole thing:

open a pull request for this branch

Claude writes the title, drafts the description, opens the PR, and hands you the link. You made the call that it’s ready to propose; Claude did the paperwork.

What’s next

Once your PR is open, people review it — and leave comments. For a lot of people that’s the intimidating part. It’s the last piece of the loop, and it’s friendlier than it looks. Next.