PR Workflow & Code Review

Open clear, reviewable pull requests. Write good PR descriptions, structure commits, leave actionable review comments, and respond gracefully to feedback.

pull requestcode reviewPR templateetiquette

Duration

⏱ About 1.5 hours

Level

📊 Intermediate

Prerequisite

🎯 git-coop-02

OUTCOME

PRs that get merged quickly because they are easy to review

What you'll learn

1Write a good PR title and description
2Keep PRs small and focused
3Leave specific, kind, actionable review comments
4Respond to feedback without ego

1. Anatomy of a Good PR

Title — what changed, in one line ("Fix login redirect on Safari")
Why — what problem this solves; link to issue if any
What — short summary of the approach
How to test — concrete steps for reviewers
Screenshots — required for any visible change

markdown

## What
Fixes the login redirect loop when Safari blocks 3rd-party cookies.

## Why
Users on Safari got bounced back to /login after sign-in. Closes #123.

## How
- Switched from cookie-based session check to /api/me
- Added retry on first 401

## Test
1. Open in Safari with cross-site cookies blocked
2. Sign in
3. Confirm you stay on /dashboard

2. Keep It Small

Aim for < 400 lines of diff
One topic per PR
Refactor and feature change in separate PRs
Big PRs sit unreviewed forever

3. Reviewing Well

Comment on the code, not the person
Prefer questions over commands ("What about X case?")
Label suggestions: nit:, suggestion:, blocking:
Approve when it is good enough, not perfect
Use GitHub Suggestions to propose small fixes inline

4. Receiving Reviews

Assume good intent
Disagree with reason, not emotion
Push fixes as new commits (don't force-push during review)
Mark threads resolved when addressed

Example code / lecture materials

All lecture materials and example code are openly available on GitHub.

View on GitHub ↗