A git code review process is a loop: a branch off main, a small pull request with a description that says why, automated checks that run before any human looks, a review that separates blocking comments from suggestions, a preview deploy so the reviewer can use the change rather than imagine it, a protected main branch that refuses merges without approval and green checks, and a merge that deploys. Most teams have the first four. The two they skip are the preview deploy and the protection rules, and those are the two that turn review from a formality into a gate.
The pages that rank for this are lists of etiquette: be kind, be specific, respect people’s time. All true and none of it is a process. A process is the sequence of mechanical steps that happen to every change, with the human judgement placed where it is useful. Here is the loop, step by step, with the configuration that makes each step happen automatically.
Table of contents
- Step 1: the branch and the size
- Step 2: the pull request and its description
- Step 3: checks before humans
- Step 4: the review itself
- Step 5: the preview deploy, which most teams skip
- Step 6: the protected main branch, which most teams also skip
- Step 7: merge, deploy, and the rollback that makes review honest
- How this fits the rest of the stack
- FAQ
Step 1: the branch and the size
Every change starts on a branch from main, named for what it does. That is the easy part. The decision that shapes the whole review is how big the change is allowed to be.
The reviewable size is a few hundred lines. Past that, reviewers skim, and a skimmed review approves anything. A feature that needs two thousand lines is five pull requests, stacked so that each depends on the last, or split into a refactor that changes no behaviour and a feature that does. Teams that enforce a size limit get faster reviews and fewer bugs; teams that do not get rubber stamps.
git switch -c feat/invoice-export main
# work, commit in small steps
git push -u origin feat/invoice-exportStep 2: the pull request and its description
The pull request is the unit of review. Its description is read by the reviewer now and by whoever runs git blame in two years, and it should answer three things: what changed, why, and how to check it. A link to a ticket is not a description; it forces the reviewer to switch tools to find out what they are looking at.
A template in the repository makes this automatic.
## What
## Why
## How to test
## Risk
- [ ] Touches the database schema
- [ ] Changes an environment variable
- [ ] Needs a rollback planOpen it as a draft while the checks run. Mark it ready when it is actually ready; a request for review is a request for someone’s time.
Step 3: checks before humans
Nothing should reach a reviewer that a machine could have rejected. Lint, format, type-check, unit tests, and a build all run on every push to the pull request, and the result shows on the pull request before anyone is asked to look.
This is the step that respects the reviewer’s time far more than any etiquette rule. A reviewer who has to point out a failing test is doing the CI’s job; a reviewer who sees green checks can spend their attention on design and correctness.
Add one more check that most pipelines lack: a build of the deployable artifact. Tests passing and the build failing is a common combination, and the review is the wrong place to discover it.
Step 4: the review itself
With the mechanical checks done, the human review looks at four things, in this order: does the change do what the description says, is there a simpler way, what breaks if this is wrong, and only then style. Style last, because the formatter should have handled it and because style comments crowd out the ones that matter.
Label every comment so the author knows what is required. The convention that works:
- blocking: must change before merge.
- suggestion: take it or leave it.
- question: the reviewer wants to understand, not to change anything.
- nit: trivial, optional, the reviewer would not mention it if it were not right there.
Then choose one of three outcomes: approve, request changes, or comment. Request changes only with at least one blocking comment attached. Approve with unresolved nits is fine; the author fixes them or does not.
Two rules of timing. The first review within a working day, or the author has moved on and the context is cold. And the reviewer reviews the whole change once rather than trickling comments over three days.
Step 5: the preview deploy, which most teams skip
Reading a diff tells you what the code does. Using the change tells you whether it works. A preview deploy, a running copy of the application built from the pull request branch at its own URL, is the difference between the two.
With a preview, the reviewer clicks through the feature, the designer checks the layout, and the product owner confirms the behaviour, all before merge. Without one, all three happen after merge, on staging if there is one and on production if there is not.
This is a hosting feature, not a git feature. The host watches the repository, builds every pull request branch, and posts the URL back on the pull request. On RunxBuild, a service deploys from a repository through the GitHub connection and every deploy produces a build log and a live route; see deploying from GitHub on RunxBuild for the connection. The preview needs its own database or a disposable copy, which is where a managed database with fast provisioning matters, because a preview that shares production’s database is not a preview.
Step 6: the protected main branch, which most teams also skip
Everything above is convention until the repository enforces it. Branch protection rules on main are what make the process a gate rather than a habit that erodes under deadline.
The rules worth turning on:
- Require a pull request before merging. No direct pushes to main, including by administrators.
- Require one approval, and dismiss stale approvals when new commits are pushed, so an approval of version one does not carry over to version four.
- Require status checks to pass, naming the specific checks, so a pipeline that was accidentally disabled cannot pass by absence.
- Require the branch to be up to date before merging, or use a merge queue, so that two pull requests that pass separately cannot break main together.
- Require conversation resolution, so blocking comments cannot be merged around.
Set these once and the process runs itself. The team can still bypass them in an emergency by changing the rule, which leaves an audit trail, which is the point.
Step 7: merge, deploy, and the rollback that makes review honest
Squash merge for most teams, so main has one commit per pull request with the description as the message. Merge triggers the production deploy from main; the same build that passed the checks is what ships.
The last piece is rollback. A review process with no rollback carries every mistake for as long as it takes to write and review a fix. With a one-click rollback to the previous deploy, a bad merge is undone in a minute and the fix gets a proper review instead of a panicked one. Review can afford to be a gate precisely because the gate is not the last line of defence.
A prototype without logs is a mystery with a URL, and a review process without rollback is a courtroom with no appeal. Both are fixable in an afternoon.
How this fits the rest of the stack
The loop is seven steps and two of them are configuration rather than culture: the preview deploy and the protection rules. Turn those on and the rest follows, because the repository refuses to let it be skipped. If the preview deploys need their own service and database, the RunxBuild hosting calculator shows what a service plus a managed database costs so the preview environment has a number attached before the team argues about it, and the dashboard is where the repository connection and the rollback button live.
Useful related references:
- GitHub Merge Queue: What It Fixes, and the CI Change You Must Make
- Branch Deploy on Netlify: How It Works and When to Use One
- Git Merge Branch Into Main Without the Conflict Panic
- Deploying from GitHub on RunxBuild
FAQ
What is a good git code review process?
Branch from main, open a small pull request with a description that says what, why and how to test, run automated checks before any human reviews, review with labelled comments, use a preview deploy to try the change, protect main so merges need approval and green checks, then merge and deploy with rollback available.
How big should a pull request be?
A few hundred lines at most. Beyond that, reviewers skim and approve. Split larger work into stacked pull requests or separate a behaviour-preserving refactor from the feature change.
What should a code reviewer look for?
In order: does it do what the description says, is there a simpler way, what breaks if it is wrong, and only then style. Formatting and lint should already have been handled by automated checks before the review starts.
What are branch protection rules?
Repository settings that enforce the process on main: require a pull request, require approvals, dismiss stale approvals on new commits, require named status checks to pass, require the branch to be up to date, and require conversations to be resolved before merging.
What is a preview deploy?
A running copy of the application built from the pull request branch at its own URL, so reviewers can use the change rather than only read it. It is provided by the host that builds the repository, and it needs its own database or a disposable copy rather than sharing production data.