creating-pr

Creating a PR

Package work into a pull request that's easy to review and merge.

Workflow

1. Prepare the Branch

Before creating the PR:

# Ensure branch is up to date with base
git fetch origin
git rebase origin/main  # or merge, depending on project convention

# Check what will be in the PR
git log origin/main..HEAD --oneline
git diff origin/main --stat

Squash fixup commits if the project prefers clean history. Keep logical commits separate if the project prefers granular history.

2. Write the Title

Format: <type>: <short description>

Type	When
feat	New feature
fix	Bug fix
refactor	Code change that neither fixes a bug nor adds a feature
docs	Documentation only
test	Adding or fixing tests
chore	Build, CI, deps, or tooling
perf	Performance improvement

Examples:

• feat: add dark mode toggle to settings page
• fix: prevent duplicate form submissions on checkout
• refactor: extract auth middleware into shared module

3. Write the Description

Use this structure:

## Summary

1-3 sentences explaining what this PR does and why.

Closes #123

## Changes

- Added `ThemeToggle` component with system/light/dark options
- Updated `Layout` to read theme from context
- Added theme persistence to localStorage

## Test Plan

- [ ] Toggle between light/dark/system themes
- [ ] Refresh page — theme persists
- [ ] Check no flash of unstyled content on load

4. Self-Review

Before requesting review:

• Read every line of the diff yourself
• Remove debug code (console.log, TODO, commented-out code)
• Verify tests pass: npm test
• Verify types: npx tsc --noEmit
• Verify lint: npm run lint
• Check for files that shouldn't be committed (.env, lockfile conflicts)

5. Create the PR

git push -u origin HEAD
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
...

## Changes
...

## Test Plan
...
EOF
)"

6. Request Review

• Tag the appropriate reviewers (code owners, domain experts)
• If the PR is large (>400 lines), add a comment explaining the best order to review files
• If the PR depends on another PR, note it in the description
• Label the PR appropriately (feature, bug, breaking change, etc.)

Tips

• Small PRs get reviewed faster — aim for <300 lines changed
• If a PR is too big, split it into stacked PRs
• Screenshots/recordings for UI changes make review much faster
• Draft PRs are useful for early feedback before the work is complete