iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

Pull Requests

Pull requests: the unit of code review. Conventions, draft PRs, templates, suggestions, and the merge strategies.

Git — pull requests

EXAMPLE
# ===== A PR is a proposal =====
# A pull request says: 'here is a branch; consider merging it'.
# It's the unit of code review on GitHub, GitLab, Bitbucket.

# ===== Open a PR =====
gh pr create --title 'feat: add tax field' --body 'Adds tax to Order model'
gh pr create --draft
gh pr create --web    # open browser

# Or push to a branch and the host shows a 'create PR' link.

# ===== PR template =====
# .github/pull_request_template.md
## Summary
- What changes and WHY

## Test plan
- [ ] Unit tests pass
- [ ] Manual test on staging
- [ ] No console errors

## Screenshots (UI changes)
<!-- attach -->

## Related issues
Closes #123

# Auto-fills new PRs; helps reviewers know what to look for.

# ===== Draft PRs =====
# Open as draft when work-in-progress; CI runs but it isn't ready to merge.
# Mark Ready for review when done.

# ===== Conventions =====
# Title: type(scope): subject  (Conventional Commits)
#   feat(orders): add tax field
#   fix(login): handle empty password
#   docs(readme): clarify install
#
# Body:
#   What + WHY (not just what)
#   Test plan
#   Linked issues
#   Screenshots for UI

# ===== Code review etiquette =====
# Author:
# - Self-review BEFORE marking ready
# - Small PRs (< 400 lines diff)
# - Respond to every comment
# - Re-request review after fixes
# Reviewer:
# - Block on correctness; suggest on style
# - Use 'suggestion' blocks for inline diffs:

\`\`\`suggestion
const total = subtotal + tax;
\`\`\`

# - Be kind; ask why, suggest how
# - Approve when ready; request changes when not

# ===== Merge strategies =====
# Squash and merge: one commit on main; cleanest history (most teams)
# Rebase and merge: linear history; preserves individual commits
# Merge commit: preserves branch shape; can clutter

# Pick one strategy + enforce via branch protection.

# ===== Branch protection =====
# Require:
# - PR review (1+ approvals)
# - All status checks pass
# - Up-to-date branch before merge
# - Linear history (no merge commits)
# - Signed commits

# ===== Auto-merge =====
gh pr merge --auto --squash
# Merges automatically when all checks pass + reviewers approve.

# ===== Merge queue =====
# Sequentially merges PRs, retesting each against latest trunk.
# Prevents 'race' merges where each PR is green individually but breaks main combined.

# ===== Useful commands =====
gh pr list
gh pr view 123
gh pr checkout 123
gh pr diff 123
gh pr review 123 --approve
gh pr merge 123 --squash --delete-branch
gh pr close 123

# ===== Patterns =====
# - Conventional Commit titles
# - Templates with summary + test plan
# - Small PRs; reviewable in 10 minutes
# - Auto-merge + merge queue for busy teams
# - Branch protection on default branch

# ===== Pitfalls =====
# - Mega-PRs (> 1000 lines) -> hard to review properly
# - 'LGTM' without reading
# - No template -> inconsistent context
# - Mixing styles (squash + merge commits) -> messy history

Why it matters

Pull requests are the unit of code review. Small, conventional title, template-driven, draft when WIP, squash-merge for clean history. Add branch protection + auto-merge + merge queue and the team can ship safely at speed.

Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.

Example

Example
gh pr create --title 'Fix login' --body 'Closes #42'
gh pr view
gh pr merge --squash
Try it Yourself »

Discussion

Loading…