Summary: Pull requests

The mechanical loop

1. Branch (L5)
2. Push the branch: git push -u origin <branch-name>
3. Open a PR on the platform UI
4. Write the description (canonical structure)
5. Request reviewers
6. Address review comments (push fixes as new commits)
7. Get approval
8. Merge (pick a strategy)
9. Delete the branch

The canonical PR description structure

## What this changes
## Why this matters
## How it was tested
## Notes for the reviewer

Optional: Screenshots, Breaking changes, Migration plan, Rollback plan.

The three merge strategies

Strategy	What it does	When to use
Merge commit	Creates merge node with two parents; preserves all branch commits	Long-lived feature branches, when history matters
Squash	Combines all branch commits into one new commit on main	Short-lived feature branches with messy WIP commits (most common default)
Rebase	Replays branch commits as new commits on top of main	Teams that want linear history with all commits preserved (advanced)

Code review, author etiquette

• Read your own diff first
• Run tests locally
• Self-review with comments
• Respond to every reviewer comment
• Push fixes as new commits (don’t force-push during review)
• Disagree with explanation, not silence

Code review, reviewer etiquette

• Respond within 1 business day
• Review the code, not the person
• Be specific
• Tag blocking vs non-blocking (blocking: / nit:)
• Approve when good enough, not perfect

The 8 anti-patterns to avoid

1. The mega-PR
2. The unrelated changes PR
3. The PR with no description
4. The PR that updates over time without re-summarizing
5. The PR that includes generated code in the diff
6. The PR with no tests
7. The PR opened on Friday at 5pm
8. The “I’ll just merge it myself” PR

The institutional memory principle

A good PR description answers “why does this code exist?” for the future debugger reading git blame six months from now. Three minutes of writing pays off in hours saved over the lifetime of the code.

What you carry into L7

You can open, describe, review, and merge PRs. L7 covers what happens when two branches both modified the same lines and you have to resolve the conflict. The PR loop continues to work; you just add a conflict-resolution step before merge.

Voice anchor

Git stores snapshots. Every other command is just navigating those snapshots.

A pull request is a proposal to merge one set of snapshots into another.