cloudparts

Gerrit Code Review

A self-hosted Git server built around code review: every commit is pushed for review first, reviewers vote on it, and only an approved change is merged into the branch. Android and Chromium use it.

What it is
Version control
Type
Open source
Made by
Google and the Gerrit community
License
Apache 2.0
Facts checked
20 October 2026
Website Source code

What it is

Gerrit is a Java server that hosts Git repositories and puts a review step in front of every branch. Developers don’t push to main; they push to the special ref refs/for/main, and Gerrit turns each new commit into a change waiting for review. A commit-msg hook adds a Change-Id: line to every commit message. To address comments you amend the commit, keep that line, and push again: Gerrit adds the new version to the same change as another patch set, so the review keeps its history across amends and rebases.

Reviewers comment on diffs and vote on labels. By default Code-Review runs from −2 (“must not be submitted”, a veto) to +2 (approved), and the default submit requirement is at least one +2 and no −2; projects often add a Verified label, from −1 (build or tests failed) to +1. The unit of review is a single commit, not a branch, so a large piece of work becomes a chain of small dependent changes, each reviewed and updated on its own. Since Gerrit 3.0 (May 2019) changes, comments, accounts and groups are stored in Git itself, in a format called NoteDb, instead of a separate SQL database.

The Android Open Source Project reviews all its code in Gerrit (uploads go through repo upload), and so does Chromium (through git cl upload). A new minor version ships about every six months: 3.13.0 on November 10, 2025 and 3.14.0 on May 15, 2026, with 3.14.4 the latest in September 2026 and 3.15.0 planned for November 13, 2026. Version 3.14 turned on Review Agent, AI-assisted review, by default whenever a plugin providing an AI review model is installed; private changes are not shared with it.

Why teams pick it

  • Review is enforced by the server, not by convention: changes reach a branch only through submit rules such as one +2, no −2 and a passing Verified vote
  • Reviews single commits, so big work can land as a chain of small changes, each reviewed and amended separately with its full patch-set history
  • Proven at very large scale on projects such as Android and Chromium, which run their own public Gerrit instances
  • Free software under Apache 2.0, and since 3.0 the review data lives in Git repositories rather than a separate database

Watch out for

  • An unfamiliar workflow for people used to pull requests: install a commit hook, push to refs/for/…, and amend commits instead of adding fix-up commits
  • A review server, not a whole forge: there is no issue tracker or CI built in, so those come from separate tools
  • You run it yourself, and some upgrades need a full reindex (3.14 moved the changes index from version 87 to 88)
  • Only the newest minor versions are supported: 3.11 reached end of life when 3.14 shipped, so staying supported means upgrading about once a year

Alternatives

What all version control have in common →Compare side by side →
Apache SubversionOpen sourceThe centralized version control system that replaced CVS: one server holds the history as a single numbered sequence of atomic commits, and clients check out any directory of it.AWS CodeCommitAWSAWS’s managed Git hosting: private repositories inside an AWS account, with access controlled by IAM instead of separate user accounts, pull requests with approval rules, and triggers into other AWS services.Azure ReposAzureMicrosoft’s hosted Git repositories, part of Azure DevOps: pull requests guarded by branch policies that can require reviewers, linked work items and a passing build, plus the older centralized Team Foundation Version Control.BitbucketCommercialAtlassian’s Git host, built to sit next to Jira: pull requests, code review and Bitbucket Pipelines CI, as the Bitbucket Cloud service or the self-managed Bitbucket Data Center.CodebergCommercialA public, non-profit Git forge for free and open-source projects, run on Forgejo by Codeberg e.V., a member-owned association in Berlin: repositories, issues, pull requests, CI, static pages and translations without a company behind them.ForgejoOpen sourceA self-hosted Git forge, like a small GitHub you run yourself: repositories, pull requests, issues, a package registry and built-in CI in one Go program, developed by a community under the non-profit Codeberg e.V. as a hard fork of Gitea.FossilOpen sourceA distributed version control system from the author of SQLite that keeps a whole project (code, tickets, wiki, forum and chat) in one SQLite database file, served by one small executable with its own web interface.GitOpen sourceThe distributed version control system almost everyone uses: every clone holds the full history, stored as objects named by the hash of their content.+1 Git LFSGiteaOpen sourceA lightweight, self-hosted Git forge in one Go program: repositories, pull requests, issues, a package registry and GitHub Actions-style CI, under the MIT license.GitHubCommercialThe largest Git host: repositories, pull requests, code review, issues and packages in one web service, owned by Microsoft since 2018 and used by more than 180 million developers.GitLabCommercialA Git forge sold as one application for the whole software lifecycle, from issues and merge requests to built-in CI/CD, packages and security scanning, that you can use on GitLab.com or run yourself.JujutsuExperimentalOpen sourceA Git-compatible version control system, run as jj, where the working copy is itself a commit, every operation can be undone, and conflicts are stored in commits instead of stopping you.MercurialOpen sourceA distributed version control system from the same month as Git, written mostly in Python, with a smaller command set, append-only storage and “phases” that stop you rewriting history others already have.Perforce P4RenamedCommercialA centralized version control server built for huge repositories and big binary files, long the standard in game studios: the server knows who has every file open, can lock files exclusively, and structures branches as streams.PijulBetaOpen sourceA distributed version control system that stores changes instead of snapshots, built on a mathematical theory of patches: independent changes apply in any order with the same result, and a conflict, once resolved, stays resolved.PiperCommercialGoogle’s in-house centralized version control system, which holds nearly all of the company’s code in one repository that tens of thousands of engineers edit at head through workspaces stored in the cloud.RadicleOpen sourceA peer-to-peer code forge built on Git: every user runs a node that stores and shares repositories, and issues, patches and reviews travel inside the repository as signed Git objects, with no central server.SaplingOpen sourceMeta’s source control system, grown out of Mercurial: an open-source sl client that works with Git repositories and makes stacks of commits and undo easy, plus a server and virtual filesystem that scale it to Meta’s monorepo.ScionCommercialAnthropic’s in-house version control system for its monorepo, built for clients that are always online: the server makes commits and answers history questions, and clients fetch only the files they read.Secure Source ManagerGoogle CloudGoogle Cloud’s managed Git forge: each customer gets its own single-tenant instance in one region, with repositories, pull requests, issues and branch protection, all behind Google Cloud IAM and private networking.Unity Version ControlRenamedCommercialUnity’s version control system, formerly Plastic SCM: one repository that programmers can use distributed, with branches and push and pull, while artists check files in straight to the server and lock what they can’t merge.

How it fits with other technologies

Upload a change for review, then a second patch set · bash

# once per clone: the hook that adds a Change-Id line to each commit message
scp -p mygerrit:hooks/commit-msg .git/hooks/

git commit -m "Extend login session timeout"
git push origin HEAD:refs/for/main               # creates a change for review on main

# reviewer asks for a fix: amend, keep the Change-Id, push again
git commit --amend
git push origin HEAD:refs/for/main -o topic=login  # patch set 2 of the same change

See it in a real stack

No architecture uses Gerrit Code Review yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2005–2026

Gerrit comes from Google’s internal code review. In 2005 Guido van Rossum began Mondrian, a tool for reviewing every change before it was submitted to Google’s central Perforce repository; it depended on Google-only services such as Bigtable, so it could not be released. In 2008 he open-sourced parts of it as Rietveld, which ran on Google App Engine and worked with Subversion. Rietveld was strictly advisory: it did not stop anyone from submitting unreviewed code.

Android had chosen Git, and its engineers wanted something like Mondrian for it. App Engine was a deal-breaker, because the phone makers working on Android keep internal repositories and won’t rely on an outside service. Gerrit started as a set of patches to Rietveld for the Android Open Source Project and became a fork once it added access control that van Rossum did not want in Rietveld’s code. It is named after Gerrit Rietveld, the Dutch architect after whom Rietveld was named. Shawn Pearce, who had reimplemented Git in Java as JGit, led the project, and Gerrit 2.0 (January 2009) was a full rewrite from Python on App Engine to Java with a SQL database. By October 2009 HTC, Qualcomm, TI, Sony Ericsson and Google were running it.

Over the next decade Gerrit moved its data into Git. Pearce told LWN in 2009 that Gerrit not working offline was “a bug” and listed storing metadata in Git as planned work; Gerrit 3.0, in May 2019, removed the old database (“ReviewDb”) for changes, accounts, groups and projects, and dropped the old GWT web interface for the newer PolyGerrit one. Releases now come about every six months, and 3.14 (May 2026) added AI-assisted review as a built-in step.

Why it’s built this way

Enforce review on the server
Rietveld only advised; nothing stopped a direct submit. Android’s partners needed control over who could change what, and adding those access-control features is what turned Gerrit from a set of Rietveld patches into a fork.
Review one commit at a time, tracked by a Change-Id
A commit’s hash changes every time it is amended or rebased. A Change-Id line in the message stays the same, so Gerrit can recognize a reworked commit as a new patch set of the same change instead of a new review.
Java and JGit instead of the git program
JGit let the server read and write repositories directly, without starting the C git binary for each operation, and most Android developers already worked in Java.
Store review data in Git (NoteDb)
Keeping changes, comments, accounts and groups in Git removed the separate SQL database from the core of a Gerrit server; only a small table of which files each user has reviewed still needs one.

Timeline

  1. 2005

    Guido van Rossum begins Mondrian, Google’s internal review tool

  2. 2008

    Rietveld released; Gerrit begins as patches to it for the Android Open Source Project

  3. 2009

    Gerrit 2.0, the Java rewrite (January 26)

  4. 2019

    Gerrit 3.0 removes ReviewDb and the GWT interface (May 15)

  5. 2025

    Gerrit 3.13.0 (November 10)

  6. 2026

    Gerrit 3.14.0 with Review Agent (May 15); 3.15.0 planned for November 13

Sources13 · facts checked 20 October 2026

Improve this page on GitHub