Gerrit and the Institutionalization of Mandatory Code Review
Gerrit put code review directly in the path to the shared Git branch, turning approvals, patch sets, access control, and automated requirements into enforceable pre-submit infrastructure.
Gerrit made review a gate in front of the shared branch
Many teams review code, but Gerrit was designed around a stronger workflow: proposed changes arrive in a review system before they are permitted to become part of the target branch. Gerrit’s product overview describes a framework in which code is reviewed before entering the codebase, with approvals, tests and project policies participating in whether a change can be submitted.[1] That architecture turns peer review from an informal social recommendation into infrastructure. A developer does not simply push to the main branch and ask someone to look afterward. The proposed commit becomes a review object with patch sets, comments, votes and submit requirements that must be satisfied before integration.
Review state became repository-adjacent data
A Gerrit change is more than a Git commit hash. It accumulates review votes, new patch sets and policy evaluation, creating a workflow layer around Git rather than altering Git’s object model.
The lineage ran from Mondrian to Rietveld to Gerrit
Gerrit’s own origin story traces the idea through Google’s internal Mondrian system, which supported pre-submit review for Perforce, and Guido van Rossum’s open-source Rietveld project for Subversion.[2] Rietveld made web-based peer review available outside Google but remained advisory. When the Android Open Source Project adopted Git, engineers wanted a review system with stronger access control and pre-submit enforcement. Gerrit began as patches to Rietveld for that purpose and soon diverged enough to become a separate project. The name itself refers to Dutch architect Gerrit Rietveld, extending the naming lineage.
Android supplied the forcing function
Google’s 2008 open-source blog described Gerrit as Rietveld-derived tooling for Android and paired it with Repo, which coordinated Android’s many Git repositories.[3]
Access control distinguished Gerrit from advisory review tools
The crucial change was that review could participate in authorization. Gerrit’s origin documentation says the fork from Rietveld accelerated when access-control features became important for AOSP.[2] In a shared Git repository, write permission alone is coarse: anyone allowed to push directly can bypass review unless server-side policy intervenes. Gerrit instead receives changes through controlled refs, evaluates reviewer labels and permits submission only when project requirements are met. This makes code review an institutional rule encoded by the hosting system. Organizations can define who may approve which projects, which automated checks are required and who has the right to submit.
Patch sets made revision during review a first-class operation
Review is rarely a one-shot yes-or-no event. A reviewer finds a problem, the author revises the code, and the conversation continues. Gerrit models those revisions as patch sets attached to the same logical change, preserving discussion while the underlying commit evolves. Its user documentation describes changes becoming submittable only after required review labels are satisfied and no veto conditions remain.[4] This workflow reduces the temptation to merge a provisional change merely to continue iterating on it. The review system becomes a staging area in which code can evolve while remaining outside the destination branch.
Submission is a distinct privileged action
Gerrit separates approving a patch from actually submitting it. The final merge depends on both review state and permissions, giving projects a programmable boundary around their main branches.[4]
Gerrit 2 rewrote the original implementation around Java and Git
The first Gerrit inherited Python and Google App Engine from Rietveld. Gerrit 2 was a ground-up rewrite using Java, a servlet container and a database, according to the project’s historical design notes.[2] Shawn Pearce’s first Gerrit 2 commit in November 2008 explicitly described that rewrite and is preserved in community remembrance of his role as the project’s founder.[5] The rewrite reflected how quickly a review experiment had become core infrastructure for a large open-source project. Performance, repository integration, access control and deployability were now long-term systems concerns.
Shawn Pearce tied Git and review infrastructure together
Pearce also worked on JGit and helped make Gerrit’s Git-centric architecture practical. The project’s history remains closely associated with his effort to make mandatory review usable at scale.[5]
Mandatory review changed the meaning of “push”
In a conventional central Git workflow, pushing to a branch often means publishing the change immediately. In Gerrit, pushing a commit to a review ref means proposing it. This is a subtle but important shift in developer behavior. The network operation is no longer synonymous with integration; it is the start of an institutional process. Reviewers, automated verification and policy decide whether the proposal advances. That distinction made Gerrit especially attractive to projects that wanted strong control over shared branches without abandoning distributed local Git workflows. Developers still commit and rewrite locally, but the central repository gains a formal gate.
The strength of the workflow also created cultural friction
Gerrit’s model is opinionated. Teams accustomed to lightweight pull requests may find patch-set workflows, Change-Ids, labels and submit rules more structured than necessary. Requiring review before integration can also slow trivial changes if project policy is poorly tuned. Yet those same mechanisms are why Gerrit remains valuable in organizations that want review to be non-optional. The system makes policy visible and machine-enforceable. This is a recurring tradeoff in engineering tools: flexibility feels convenient until a large organization needs guarantees, at which point explicit workflow can be easier to audit than convention.
Why Gerrit belongs in the history of code review
Gerrit belongs in software-engineering history because it institutionalized code review as a pre-submit control plane around Git. Its lineage from Mondrian and Rietveld shows how an internal review practice was progressively generalized, open-sourced and then strengthened for a large public project.[2][3] Modern platforms often present review through pull requests, but the core question Gerrit made unavoidable remains: is review merely a conversation around code, or is it a requirement the repository will enforce? Gerrit chose enforcement and built a durable architecture around that choice.
Works Cited
- 01Gerrit Code Review — Product Overview gerrit-review.googlesource.com
- 02Gerrit Code Review — Origin Story gerrit.googlesource.com
- 03Google Open Source Blog — Gerrit and Repo, the Android Source Management Tools opensource.googleblog.com
- 04Gerrit Code Review — User Guide and Submit Workflow gerrit-review.googlesource.com
- 05Repo Discuss — Remembering Shawn Pearce and the First Gerrit 2 Commit groups.google.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead