Pull requests

What this lesson covers

L6 teaches the workflow that turns “I have work on a branch” into “the team reviewed and merged my work.” It is the longest and most prose-dense lesson in T7 because it covers as much soft-skill content (PR descriptions, review etiquette) as it does mechanics.

Three load-bearing ideas:

The PR description is read by five audiences over the PR’s lifetime. Three minutes of writing saves hours of investigation over months. PR descriptions are institutional memory.
The three merge strategies (merge / squash / rebase) produce visually different histories. Most modern teams default to squash for short-lived feature PRs. Pick one as the team default; document it; follow it.
Code review etiquette is leadership development. Reviewers who give specific, kind, principled feedback grow into engineering leaders. The discipline applies symmetrically: authors should also respond to comments specifically, kindly, and from principles.

By the end of L6, the reader will be able to

Walk through the mechanical PR loop (branch, push, open PR, review, fixes, approve, merge, delete branch)
Write a PR description with the canonical structure (what / why / how tested / notes for reviewer)
Choose between merge commit / squash / rebase based on the team’s history convention
Give code review that distinguishes blocking from non-blocking concerns
Receive code review without confusing feedback on the code with feedback on themselves
Identify and avoid the 8 common PR anti-patterns
Articulate why PR descriptions function as institutional memory

Prerequisites

L1 (snapshot model)
L2 (commits)
L3 (commit hygiene); PR descriptions are commit messages scaled up
L5 (branches); you need a branch to open a PR from
A GitHub or GitLab account
A real repository to practice on (preferably one with collaborators)

Reading map

L6 is the longest lesson in T7 by design. Read it in chunks if needed.

Read first: “The mechanical flow” plus “Writing a PR description” plus “The three merge strategies.” These are the load-bearing mechanics.
Read second: “Code review etiquette, as the author” plus “as the reviewer.” These are the soft-skill foundations.
Read third: “The PR as institutional memory” plus “Common PR anti-patterns” plus the framing sections. Higher-order considerations.

New developers should read all sections; the soft-skill material is exactly where new developers most need a roadmap.

Experienced developers should focus on the “8 anti-patterns” section. Even senior engineers fall into mega-PR or unrelated-changes patterns under pressure; the explicit naming helps.

Managers and TPMs should read the dedicated framing section. The “PR review time as productivity tax” observation is operationally useful.

What this lesson deliberately does not cover

Rebasing your branch onto updated main before merge (deferred to L12)
Merge conflicts (next lesson, L7)
Branch protection rules / required reviews / CI gates (deferred to L9)
Stacked PRs / dependent PRs (advanced; deferred to L11)
AI agents authoring PRs (covered in Phase 4, foreshadowed here)
Specific platform UI walkthroughs (GitHub vs GitLab vs Bitbucket; covered in passing; the platform docs are the canonical reference)

If you want to understand merge conflicts, L7 is next. If you want platform UI specifics, the platform docs are better than this lesson.

Estimated reading + practice time

30-40 minutes for reading (longer because of the soft-skill density). 25-30 minutes for the practice exercises (includes writing a real PR description for a real PR; this is the most pedagogically valuable drill in T7).

Total: about 55-70 minutes including practice. L6 is intentionally the longest lesson in the track because it’s the highest-leverage one.