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   |

The goal: a reviewer can understand the change, test it, and approve it without asking you a single question.

Responding to code review

When a reviewer leaves a comment:

1. Respond to every comment, even 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.