Code Review on GitHub: Step-by-Step Setup and Best Practices

Most teams already have a code review tool. If you use GitHub, GitLab or Bitbucket, pull requests (or merge requests) are the tool. What varies from team to team isn’t the software, it’s the setup around it and the habits of the people using it. A well-configured repository with a clear process catches real bugs and spreads knowledge. A badly configured one produces rubber-stamp approvals and pull requests that sit for a week.

This tutorial sets up a practical review workflow on GitHub, step by step, and then covers the habits that make reviews worth doing. The same ideas apply on GitLab and Bitbucket with different menu names.

What code review is actually good for

It’s worth being clear about the goal, because it affects how you set things up. Reviews catch some bugs, but their bigger value is usually elsewhere:

Shared understanding: at least two people know how each part of the system works.
Design feedback: a second view on structure and naming before the code hardens.
Consistency: a codebase that looks like one team wrote it.
Catching the obvious: missing error handling, security mistakes, missing tests.

Anything a machine can check (formatting, lint rules, tests, known vulnerabilities) should be checked by a machine before a human looks. That keeps human attention for the things only humans can judge.

Step 1: Add automated checks that run on every pull request

Start with CI, because branch protection will depend on it. A minimal GitHub Actions workflow for a Node.js project:

# .github/workflows/pr-checks.yml
name: PR checks
on:
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test

Adjust the commands for your stack: ruff and pytest for Python, ng lint and ng test for Angular, and so on. The important part is that the job’s name, test here, will show up as a status check you can require.

Step 2: Protect the main branch

In your repository, go to Settings → Rules → Rulesets (or Settings → Branches for classic branch protection) and create a rule for main:

Require a pull request before merging, with at least one approval. Two is common for critical services. More than two usually just slows things down.
Dismiss stale approvals when new commits are pushed, so an approval covers the code that actually merges.
Require status checks to pass, and select the CI job from step 1.
Require conversation resolution, so open review comments can’t be ignored.
Block force pushes to the protected branch.

On GitHub’s Free plan, these protections are available for public repositories. Private repositories need a paid plan.

Step 3: Route reviews to the right people

A CODEOWNERS file automatically requests reviews from the people responsible for each part of the code:

# .github/CODEOWNERS
*                 @your-org/developers
/src/api/         @your-org/backend
/src/app/         @your-org/frontend
/.github/         @your-org/leads

Later lines take precedence over earlier ones. If you enable “Require review from Code Owners” in the branch rule, a change to /src/api/ can’t merge without a backend reviewer’s approval.

Step 4: Add a pull request template

Most review friction comes from missing context. A template prompts authors to supply it:

<!-- .github/pull_request_template.md -->
## What and why
<!-- What does this change do, and why is it needed? Link the issue. -->

## How to test
<!-- Steps a reviewer can follow, or the tests that cover it. -->

## Screenshots
<!-- For UI changes. -->

## Checklist
- [ ] Tests added or updated
- [ ] No secrets or debug code left in
- [ ] Docs updated if behaviour changed

Keep it short. A template with twenty checkboxes gets ticked without being read.

Step 5: Use the review features you already have

GitHub’s pull request review tools are richer than many people realise:

Inline comments: click the + next to any line in the “Files changed” tab. Drag across line numbers to comment on a range.
Start a review, not single comments: batch your comments and submit them together as “Comment”, “Approve” or “Request changes”. The author gets one notification instead of fifteen.
Suggested changes: in an inline comment, use a suggestion code block to propose the exact replacement. The author can apply it with one click.
“Viewed” checkboxes: tick files as you review them so you can pick up where you left off.
Draft pull requests: open a PR as a draft for early feedback without triggering formal review.

How much to review at once

One of the most useful pieces of evidence on review effectiveness is still a study SmartBear ran with a Cisco Systems team, covering thousands of reviews. Its main findings, as SmartBear summarises them:

Reviewers found defects most effectively when reviewing 200 to 400 lines at a time. Beyond that, the ability to find defects dropped.
Inspection rates faster than about 500 lines per hour saw a significant drop in defects found.
Effectiveness fell off after about 60 minutes of continuous reviewing.

The study is old and was run by a company selling review software, so treat the exact numbers as rough guides. The direction is consistent with most developers’ experience: small pull requests get real reviews, and huge ones get “LGTM”.

Habits for authors

Keep pull requests small and focused. One logical change per PR. If a refactor is needed first, submit it separately.
Review your own diff first. You’ll catch leftover debug code and typos before anyone else has to.
Explain the why. Reviewers can see what changed. They can’t see why.
Respond to every comment, even with “done” or a short explanation of why you disagree.

Habits for reviewers

Review promptly. A same-day first response keeps work moving. Google’s engineering practices guide suggests responding within one business day at most.
Look at design first, details second. If the approach is wrong, comments on variable names are wasted effort.
Label the weight of comments. Prefix optional suggestions with “nit:” or “optional:” so the author knows what must change and what’s taste.
Comment on the code, not the person. “This function could return early here” rather than “you forgot to return early”.
Approve when it’s better, not perfect. Google’s guide makes this point directly: approve once the change definitely improves the overall health of the code, even if it isn’t perfect.

Adding AI review tools

AI review assistants, such as GitHub’s Copilot code review and various third-party apps, can now comment on pull requests automatically. They’re useful for catching obvious issues and summarising large changes. Treat them like a linter with opinions: helpful as a first pass, not a replacement for a human who understands the system and the reason for the change.

Measuring whether it’s working

You don’t need a dashboard, but a few numbers are worth checking now and then:

Time to first review and time to merge. Long waits are usually the biggest complaint.
Pull request size. If the median is creeping up, reviews are getting shallower.
Who reviews. If one person reviews everything, you have a bottleneck and a knowledge risk.
Bugs that escaped. When a bug reaches production, look at the PR that introduced it and ask what would have caught it.

Summary

Setting up the tooling takes under an hour: a CI workflow, a branch rule, a CODEOWNERS file and a short template. Making reviews valuable takes longer, because it’s about habits: small changes, fast responses, clear context and kind, specific feedback. Get those right and the tool almost doesn’t matter.