Pull requests, end to end
Ishaan's fix is sitting on his fork. Watch what actually happens between "here's my branch" and "it's part of the project."
Ishaan's authenticated, his fix is pushed to his fork, and Vidha tells him the next step is to "open a PR." He's heard the term but never actually done it. "It's not a Git command," she says. "It's a GitHub feature built on top of everything you just learned — a proposal, basically. You're asking the real repo to pull your branch in."
What a pull request actually bundles together
A PR page is one URL that combines several things you already understand separately: the diff between his branch and main (Chapter 8's territory), a running comment thread, the CI status once Chapter 17 wires that up, and — the part that hasn't happened yet in this story — review: other people reading the change and reacting to it before it becomes permanent.
Opening it
Push, then follow the link GitHub hands you
Ishaan already pushed fix/typo-in-staging-page to his fork in Chapter 12. GitHub's response to that push included a direct link to open a PR from it — he clicks through.
Title and description
Same discipline as a commit message (Chapter 2): short, specific title. In the body, he writes what changed and why — one sentence, since it's a genuine one-line typo fix — plus Closes #7, referencing the actual "good first issue" Vidha filed asking for exactly this kind of pass through the beginner docs.
Base and compare
GitHub shows two dropdowns: base repository (accelerate-muj/resources, main) and head repository (his fork, his branch). Because he came in through the "compare & pull request" link, both are already set correctly — but it's worth knowing this is configurable, since it's the exact mechanism Chapter 11's fork diagram was describing.
What Vidha sees on the other side
PR #12 shows up in the repo's Pull requests tab. Vidha opens the "Files changed" tab — one line removed, one line added, exactly the typo fix. She's reviewing as a real maintainer would, not just skimming:
She doesn't just say it — she leaves it as a suggestion, a special comment format that renders as a one-click-appliable diff:
```suggestion
the staging area lets you separate ready changes from unfinished ones
```Ishaan clicks "Commit suggestion" right on the PR page. A new commit appears on his branch — GitHub made it directly, no terminal involved — and the PR updates live. This is worth noticing: review comments aren't just talk, they can directly produce commits, and the whole exchange is visible to anyone who reads the PR later, including future contributors trying to understand why the wording is what it is.
The vocabulary of a review
| Action | Meaning | Blocks merge? |
|---|---|---|
| Comment | A general note or question on a line or the PR as a whole | No |
| Suggestion | A specific proposed replacement, one click to apply | No |
| Request changes | Formal "not yet" — names something that must be addressed | Yes, under branch protection (Chapter 15) |
| Approve | Formal "this is ready as far as I'm concerned" | Unblocks merge, once required approvals are met |
Vidha's comment here was just a comment with a suggestion attached — friendly, not blocking. On a PR with a real design concern, "Request changes" is the tool that actually stops a merge from happening until the concern's addressed, which matters once Chapter 15 makes that enforceable rather than just polite convention.
Responding well, as the author
Ishaan applies the suggestion, then replies "done" on the original thread rather than leaving it silent — silence on a review comment reads as ignoring it, even when the fix has technically happened. If he'd disagreed with her wording instead, the expectation would be the same: reply with reasoning, not just re-push and hope she notices. Reviewers are spending their own time; a PR author owes them an actual response.
rebase -i and force-push partway through. It silently invalidates whatever mental model the reviewer built of what they've already checked, and GitHub's own "what changed since I last looked" view stops being trustworthy. Save the cleanup rebase, if you want one, for just before merge — and Accelerate's squash-merge default (Chapter 14) usually makes that cleanup unnecessary anyway.
Approval and merge
Vidha clicks Approve. Since resources requires one approval before merge (Chapter 15), the merge button lights up. She picks "Squash and merge" — Ishaan's two commits (the original fix, plus the suggestion commit) collapse into one clean entry on main, credited to him, referencing #7. His branch auto-deletes from his fork's remote copy; the fork itself stays his, ready for next time.
Trailers that do real work
| Write this | Effect |
|---|---|
Closes #7 / Fixes #7 / Resolves #7 in the PR body | Merging auto-closes issue #7 |
#7 in any comment | Cross-reference; both sides link to each other |
@vidhaaaaaa | Notifies that person directly |
@accelerate-muj/core-committee | Notifies the whole team |
Co-authored-by: Name <email> as a commit trailer | Both names get attributed on that commit — relevant again in Chapter 14 |
PR #12 is merged. That's Ishaan's first real contribution, done properly, start to finish. But watch what the merge button actually did to the commit history — it picked "squash," collapsing two commits into one. Rachit's redesign, back in Chapter 8, landed as a full merge commit with both parents preserved. Those aren't arbitrary choices, and picking the wrong one for the wrong situation causes exactly the kind of tangled history Chapter 9 was trying to clean up.