Git PR Workflow & Code Review: How to Get Your PRs Reviewed Fast

You opened a PR titled "changes". No description, no context, no ticket link. Three days passed. Your team lead finally messaged you: "What's this for?" You explained it verbally. The review happened, but slower and less thoroughly than it should have. Here's how to prevent that.

GitHub Flow in One Diagram

GitHub Flow has exactly five steps:

main
  └── checkout feature branch
        └── commit, commit, commit
              └── open Pull Request
                    └── review & approve
                          └── merge to main → deploy

Everything happens at the PR step. That's where the quality gate is.

The PR Description Template

Copy this into every PR you open:

## What
One sentence summary of the change.

## Why
Ticket: [DEV-42](link-to-ticket)
Brief context, why does this change need to exist?

## How to Test
1. Checkout this branch
2. Run `pnpm dev`
3. Navigate to /login
4. Verify that [expected behavior]

## Screenshots (if UI change)
| Before | After |
|--------|-------|
| img    | img   |

A reviewer who reads your PR description should be able to understand the change, test it, and approve it, without asking you a single question. That's the goal.

Responding to Code Review

When a reviewer leaves a comment:

1. Respond to every comment, even if it's just "Done" or "Good catch, fixed in the latest commit." Silence reads as ignoring.

2. Don't argue in comments. If you disagree, say "I see your point, but I went this way because [reason]. Open to discussion." Then have a call if needed.

3. Only resolve conversations after addressing them, clicking "Resolve" before fixing is a trust killer.

4. Re-request review after pushing fixes, don't expect reviewers to notice a new push. Click the re-request button next to their name.

Acceptance Criteria

Before merging, every box must be checked:

☐ PR title clearly describes the change (not "fix" or "update")

☐ PR description fills all four sections: What, Why, How to Test, Screenshots (if UI)

☐ PR is linked to the ticket

☐ CI checks (lint, tests) pass before requesting review

☐ All review comments responded to (not just silently resolved)

☐ At least one approval before merge

☐ You did NOT self-merge without a second pair of eyes

Common Mistakes

❌ Giant PRs (+500 lines), no one wants to review a novel. Keep PRs under 400 lines where possible.

❌ Self-merging the moment you open the PR, at least one person should see the code.

❌ Opening a PR and never following up, ping reviewers politely after 24 hours if there's no response.

TL;DR

Write PRs for the reviewer, not yourself. Fill the template. Respond to every comment. Never self-merge. A good PR is a gift to your team.