Using Gerrit to Strengthen Git Code Review and Automated Code Analysis

Gerrit adds a structured review gate on top of Git, helping teams run human review and automated checks before code reaches shared branches. If you manage CI/CD or repository governance, this walkthrough shows how Gerrit can improve code analysis quality and traceability without replacing Git itself.

Originally published on 2014-07-22; fully revised and updated.

What Gerrit adds beyond plain Git

Git handles version control. Gerrit adds a review system where each proposed change is evaluated before merge. Instead of pushing directly to a branch, developers push to a review reference (commonly refs/for/branch), and Gerrit creates a reviewable change.

• Patch set iterations: update the same review with amended commits.
• Review labels: teams can use labels such as Code-Review and Verified to gate submit.
• Audit trail: comments, votes, and CI outcomes are attached to each change.
• Submit control: merge can be blocked until required approvals and checks pass.

Typical Gerrit review and analysis workflow

flowchart TD
    A[Developer commits locally] --> B[Push to refs/for/main]
    B --> C[Gerrit creates change and patch set]
    C --> D[Reviewers comment and vote]
    C --> E[CI runs lint tests and security scans]
    D --> F{Approvals and CI green}
    E --> F
    F -- no --> G[Developer amends commit and pushes again]
    G --> C
    F -- yes --> H[Submit and merge to main]

Core commands: from local commit to Gerrit review

1) Clone and install the commit-msg hook

The commit-msg hook adds a Change-Id, which Gerrit uses to track new patch sets for the same review.

git clone ssh://USER@gerrit.example.com:29418/myteam/myrepo.git
cd myrepo
scp -p -P 29418 USER@gerrit.example.com:hooks/commit-msg .git/hooks/Code language: PHP (php)

2) Push a new change for review

git checkout -b feature/improve-parser
git add .
git commit -m "Refactor parser error handling"
git push origin HEAD:refs/for/mainCode language: JavaScript (javascript)

3) Update the same change as a new patch set

git add parser.py
git commit --amend
git push origin HEAD:refs/for/main

4) Fetch a specific patch set locally

git fetch origin refs/changes/45/12345/3
git checkout FETCH_HEAD

5) Example CI vote back to Gerrit

Many CI systems report status back to Gerrit as a review vote and message.

ssh -p 29418 USER@gerrit.example.com gerrit review \
  --verified +1 \
  --message "CI passed: lint, unit tests, sast" \
  12345,3Code language: CSS (css)

Where to run code analysis: pre-submit vs post-submit

Gerrit and PR-style platforms: quick comparison

Original video resource

The original post was a short teaser that pointed to a video demonstration. You can still access that reference here: Gerrit video link.

Best practices and common pitfalls

• Keep pre-submit checks fast; move heavy scans to asynchronous or staged pipelines.
• Define clear submit rules so reviewers know what is required to merge.
• Standardize label usage (for example, who can vote Verified vs Code-Review).
• Document how developers should update patch sets (amend vs new commit strategy).
• Avoid bypass pushes to protected branches except for controlled emergency paths.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.