Lesson 41.3 made work inspectable: every idea lives on its own branch. This lesson decides membership: does that branch belong in the project's accepted history? The branch is where work *can* be inspected. The pull request is where the project *decides*.

A pull request is a comparison and a discussion

A pull request (PR) is a review page that compares a branch with the branch it proposes to change. It is not merely a "please click Merge" button.

One page brings together everything a reviewer needs:

• Changed files and the full diff
• The branch's commits
• Automated checks (tests, lint, build)
• Comments and requested changes
• Often a preview deployment — a disposable runnable version of the branch

The authoritative terminology lives in the GitHub pull requests documentation. Interfaces shift; the concept holds: comparison plus discussion plus decision.

The complete delivery path

No step is optional for work that matters:

task brief → branch → implementation → diff + tests → pull request
  → review / preview / requested changes → merge into main → deployment check

Read it as gates, not paperwork. The brief bounds the work. The branch isolates it. The diff and tests are the author's evidence. The PR opens it to others. Review and preview test the claim. Merge brings accepted branch changes into another branch, normally main. The deployment check confirms the live product still behaves.

The dashboard's source-date UI branch walks exactly this path: brief ("show the date and its missing state"), branch, implementation, diff plus citation test, PR, reviewer pass, preview click-through, merge, then a check that the deployed brief still renders.

The events finder is smaller but identical: a venue-display branch opens a PR with two screenshots — populated card and empty state — and merges only after both render.

The six-question review

Review every PR with the same checklist:

1. Does the title state the user-visible or technical outcome? 2. Does the description name scope, files/systems changed, validation, and remaining risk? 3. Does the diff include only intended work? 4. Did required checks and real verification pass — browser, API, or workflow, not just CI green? 5. Did a reviewer look closely at medium/high-risk code and permissions? 6. Is there a rollback or repair path if production surprises us?

Questions 2 and 4 do the heavy lifting. A description that lists scope, validation, and remaining risk forces the author to admit what was *not* proven. And checks alone never suffice: automated green plus a human clicking the real brief with a known date and a null date is the standard.

Question 6 separates beginners from builders. Before merging, you should know the answer: "revert this one merge" or "flip this flag" — stated in the PR, not invented during the incident.

Merge styles: pick one, stay consistent

GitHub offers several ways to bring a branch in — a merge commit that preserves every branch commit, a squash merge that compresses them into one, a rebase that replays them linearly. The concepts matter less than the discipline: the project should choose one consistent history style.

A squash merge deserves one precise understanding: it can turn several noisy work-in-progress commits ("wip," "try again," "fix typo") into one readable finished change. That readability is valuable. But squash does not make the change safer by itself. Ten unreviewed commits squashed into one unreviewed commit are still unreviewed. Safety comes from the six questions, not the merge button.

Revert: the shared-project-friendly undo

A revert is a new commit that deliberately undoes the effect of an earlier commit. History stays complete — the original commit and its reversal both remain visible — which is exactly what a shared project needs.

Contrast that with resetting local history, which rewrites or discards commits. On a private, unpushed branch, cleaning up your own checkpoints is normal. Once a change is merged and shared — pulled by teammates, built by CI, possibly deployed — rewriting it confuses everyone. Someone's copy no longer matches yours, and the record of what happened vanishes.

The rule: prefer revert for anything merged or shared. It is the normal response to a bad accepted change. It is reviewable, it is itself a PR if needed, and it preserves the audit trail a future AI session will rely on.

Preview is disposable; production is live

A PR preview is a throwaway copy built for review. Merge and deployment may affect the live public product — real data, real permissions, real traffic, real settings.

So internalize the sentence: a green preview does not prove production is identical. Previews often differ in environment variables, data volume, auth state, rate limits, and third-party behavior. The six-question review plus the post-merge deployment check exist because "it worked in preview" is necessary but never sufficient.

Teach this to every agent too: a passing preview earns a merge decision, not a victory announcement. The deployment check after merge closes the loop.

Incident: the null date that hid citations

Here is the whole system working under pressure.

The dashboard's source-date change merges cleanly. Preview looks perfect — every citation shows a crisp date. After deployment, a user report arrives: some briefs are missing citations entirely. Investigation finds the cause: the provider returns null for publishedAt on older sources, and the merged code skipped any citation without a date instead of rendering the agreed "Date unavailable" state. The branch's tests only covered known dates.

The recovery is deliberate, not panicked:

1. The team confirms the regression in the production check. 2. They revert the focused merge — one new commit, history intact, known behavior restored. 3. They open a smaller fix branch that renders the missing-date state and adds the null-date test the first branch lacked. 4. That branch walks the full path again: diff, tests with both date states, PR, preview showing "Date unavailable," merge, deployment check.

Notice what made this cheap: the original change was one focused merge, so one revert restored the baseline. Had the date logic shipped inside a giant multi-feature commit, reverting would have meant losing unrelated work too. Small branches are an incident-response strategy.

Exercise: open a real PR

Open a PR for the branch you built in Lesson 41.3. Copy this template into the description and fill every line:

## PR: <user-visible or technical outcome>

1. Outcome: ...
2. Scope / files changed: ...
3. Validation run + result (exact command + output, plus preview note): ...
4. Remaining risk (low/medium/high + what was NOT proven): ...
5. Rollback path (revert this merge / flip this flag / follow-up task): ...
6. Pre-merge gate: [ ] diff is branch-only [ ] checks + real click-through pass [ ] medium/high-risk code reviewed [ ] rollback stated

Then review the changed files as if the AI wrote them for someone else, and name one thing the preview and tests do *not* prove — data edge case, permission, production setting, traffic behavior. Write that gap into line 4.

Check your understanding

• What does a PR show that a branch alone does not organize?
• A merged change breaks production. Why revert rather than rewrite history?
• Preview is green and tests pass. Name two production realities neither proves.

Finish line

You are done when you have one PR-ready branch with an understandable description, attached evidence, and an explicit merge-or-hold decision.

Verify: confirm the title states the outcome, the description answers all five lines, the diff contains only intended work, checks plus a real click-through passed, and you can state the rollback in one sentence. If any answer is missing, the PR is a draft — label it so.

Common failure mode: merging on green preview alone, then discovering the revert is impossible because three features shared one branch. Recovery now: keep branches focused so each merge is independently revertable, and always record the rollback path before clicking Merge.