A pull request (PR) is how you ask your teammates to look over your branch before it joins main. It turns a private edit into a shared moment, everyone can see what changed, why, and weigh in. On GitHub it's the normal way teams review each other's work.
About 2 min of reading
Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.
A pull request turned a private edit into a shared moment, and the first one I opened I did not know how to finish. Let me do the part I control locally, the branch, the diff a reviewer will see, responding to a comment, then open and merge it on GitHub so the whole conversation has somewhere to live.
Open a pull request, but first put something worth reviewing on a branch. This makes a change on a feature branch while main stays clean. The reviewer will see exactly this diff against main, so it should be one small, self-contained edit, the kind of thing easy to read in a browser.
Before you run it, say out loud what it will print. Then open the answer.
Before opening anything, look at the exact diff the reviewer will see. The three dots in main...feature/login compare what the branch adds to main, not the whole history. This is the preview I take a screenshot of before I ask anyone to read it.
Before you run it, say out loud what it will print. Then open the answer.
Open the pull request on GitHub. This is the moment the edit becomes shared, the page shows the diff, a field for what changed and why, and a button to request reviewers. I paste a short note explaining the change, and the conversation starts.
Before you run it, say out loud what it will print. Then open the answer.
A reviewer comments: please rename a variable so it means more. I reply right here on the branch by editing the file and committing again, without touching main. Every change I make on the branch shows up in the same pull request, so the reviewer sees it the moment I push.
Before you run it, say out loud what it will print. Then open the answer.
The reviewer approves and merges. The branch joins main, the pull request closes as merged, and the history now shows exactly what shipped. This is the end of the conversation, the code is in, the request is done.
Before you run it, say out loud what it will print. Then open the answer.
Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.
A PR gives others a chance to check your work. Good reviewers ask questions and catch mistakes before they go live, they're doing you a favor, not nitpicking.
Once it's approved, the branch merges into main and the new work becomes part of the project. The request is done, and the history now shows exactly what shipped.
You: "Open pull request: add login page."
Reviewer: "Looks good! One small change here."
You: "Fixing it now."
Reviewer: "Approved. Merging."A PR keeps that whole back-and-forth in one place, tied to the actual code. Nobody has to describe the change over chat, everyone can read exactly what changed and leave their comments next to the relevant line.
Great start here.
Can we add a short comment on line 12?
Looks good to me. Approving.A reviewer reads the changes and leaves comments: questions, suggestions, or a plain approval. It's meant to keep the code healthy, not to score points. Every comment is a chance to learn something about how a teammate would handle a similar problem.
Please rename this variable.
"userData" tells me more than "d".When something isn't right, you request changes, which pauses the merge until it's fixed. It's a normal, polite part of the process, it just says "here's what to fix before this can merge". Being specific about what and why saves the author a guess.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.