# Gerrit, the review server where every change is a commit in its own ref namespace > Gerrit is a code review and project management tool for Git projects, built in Java, that makes review part of the push path rather than a separate merge step. Changes live as commits in a ref namespace, reviewers comment inline on a side-by-side diff, and any authorized user can submit an approved change to master. The GitHub repository is a mirror; the canonical history lives on googlesource.com. **GerritCodeReview/gerrit** — Gerrit Code Review - (mirror of https://gerrit.googlesource.com/gerrit) - Repository: https://github.com/GerritCodeReview/gerrit - Stars: 1,239 · Forks: 279 - Language: Java - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/gerritcodereview-gerrit ## The model: a change is a commit, not a pull request Gerrit's central idea is that a proposed change is a commit that lives in a namespace of refs rather than a branch waiting to be merged, and the review conversation is attached to that commit. Two objectives are stated in the project documentation, and both follow from that model. The first is that review gets easier because changes are shown side by side and any reviewer can add inline comments. The second is that project maintenance gets simpler because any authorized user can submit a change to the master repository, instead of requiring a maintainer to merge approved changes by hand. That second objective is the one that changes an organisation. Merge rights become a permission you can grant broadly, because the act of merging is no longer a separate privileged act performed by one person. The cost is that contributors must adapt to a workflow where a push creates a reviewable object rather than a branch, and where the review, the commit and the merge are the same artifact. ## This repository is a mirror, and the README is explicit about it The GitHub repository is a mirror of the canonical one on googlesource.com, and the documentation is unusually direct about what that means for contributors. Changes are submitted to the Gerrit server on gerrit-review.googlesource.com, and the project states plainly that pull requests via the GitHub mirror are not accepted. That is not a technical limitation but a policy, and the reason given is spam: membership in the repo-discuss Google Group is required in order to create issues on the tracker and in order to create Gerrit changes on the server. The README points at an announcement about reducing spam on both the issue tracker and gerrit.googlesource.com. Bug reports go to a separate issue tracker with a component filter, and installation and usage details are not in the README at all but in the documentation hosted on gerrit-review.googlesource.com. The last push to the mirror was on 2026-10-19 and the repository is not archived, and there are no GitHub releases at all, since releases are cut on the canonical server. ## Building from source with Bazel and submodules The build is the one thing the README does explain, and it is a single command once Bazel is installed. The clone has to be recursive, because the source pulls in submodules, and the build target is a release build. ``` git clone --recurse-submodules https://gerrit.googlesource.com/gerrit cd gerrit && bazel build release ``` The repository layout shows how large the project is. There is a `java/` directory for the server code and `javatests/` beside it, a `webapp/` and a `polygerrit-ui/` for the two user interface parts, a `plugins/` directory for extensions, a `Documentation/` tree, `e2e-tests/`, `prolog/` with its own `prologtests/`, `modules/`, `lib/`, `tools/`, `contrib/`, `configs/`, `resources/`, `proto/`, and `antlr3/`. The build is defined in Bazel terms, with a `MODULE.bazel`, a `MODULE.bazel.lock`, a `.bazelversion` pinning the toolchain, a `.bazelrc` and a `BUILD` file at the root, plus an `external_deps.lock.json` for the external dependency set. There is also a `Jenkinsfile`, a `.zuul.yaml` and a `package.json` for the frontend, so the build spans Bazel, a Java toolchain and a Node and TypeScript toolchain at once. ## Binary packages and the version-release counter split Installing from a package is the alternative to building, and the GerritForge and BinTray repositories are configured according to a separate guide. The Debian and Ubuntu install names an explicit version and release, the CentOS and RedHat one takes the same pair, and the Fedora one does too. The release component has a meaning that is easy to miss: it is a counter starting at 1 that indicates how many packages have been released with the same version of the software, so a rebuild of the same version gets a new release number. That is a packaging convention, and it exists because the packages are rebuilt against newer dependency versions, which is precisely the kind of change that is invisible in the version number and important in practice. The docker images live on DockerHub under the gerritcodereview user, with a CentOS 8 based image and an Ubuntu 20.04 based image, each mapping port 8080, and the release suffix in the image tag is optional, in which case the last released package of that version is installed. ## The frontend is a separate build with its own lockfiles The JavaScript side of the repository is substantial enough to deserve its own look. The `package.json` names the project `gerrit` at version 3.11.0, and its dependency list is almost entirely development tooling: eslint with the Google config, the typescript-eslint parser and plugin, prettier, rollup, terser, lit-analyzer, gts, and a set of plugins for jsdoc, lit, regex and node builtins. The runtime dependency list has a single entry, the typescript-eslint parser. The presence of lit-analyzer and the two language service packages in the resolution comments says the interface is written with web components and checked by a linter rather than by a compiler, which matches the two UI directories in the tree. There is a yarn lockfile, a pnpm lockfile and a pnpm workspace file side by side, and the setup script installs the root dependencies and then the polygerrit-ui directory and its app subdirectory separately, so the frontend is a multi-package workspace rather than one app. ## What Gerrit is the wrong tool for The design carries real costs, and they are visible in the repository layout even where the documentation is not candid about them. Contributors must use the Gerrit client flow, since the GitHub mirror refuses pull requests, which means a contributor who wants to work on Gerrit has to be willing to learn a push-to-refs workflow and, in practice, to have a reviewer for the change itself. The requirement for group membership before you can file an issue or a change is a direct consequence of spam and will stop some contributors outright. The other structural cost is that the merge model assumes a project with a defined set of authorised submitters and a clear master branch; a project that wants a lightweight, hosting-platform workflow will find the ceremony heavy. What Gerrit buys in exchange is precise: a review anchored to a commit, inline comments that cannot drift away from the line they refer to, and the ability to hand merge authority to many people without handing them the repository. ## Conclusion Adopt Gerrit if you maintain a project where review is the bottleneck and you want per-commit review with a clear link between a discussion and the exact change it covers, and skip it if your team works from a hosting platform with pull requests already, because the migration is not a matter of pointing a tool at a repository. Verify three things before you commit: that you can build it yourself, since the canonical source is a googlesource clone built with Bazel and the GitHub mirror explicitly does not accept pull requests; that you understand the ref namespace, because a change is a commit under refs/changes rather than a branch, and every custom workflow depends on that; and which GerritForge or docker image version you want, since the packaged releases carry a version and a release counter that are separate things. ## FAQ ### What is Gerrit and how does it differ from a pull request workflow? Gerrit is a code review and project management tool for Git projects. Changes are commits in a ref namespace rather than branches, reviewers comment inline on a side-by-side diff, and any authorized user can submit an approved change to the master repository instead of a maintainer merging by hand. ### Can I contribute to Gerrit through the GitHub mirror? No. The project states that pull requests via the GitHub mirror are not accepted, and that the canonical repository is on googlesource.com. Creating Gerrit changes on the gerrit-review server requires membership in the repo-discuss Google Group, and the same membership is required to create issues, because of spam abuse. ### How do I build Gerrit from source? Install Bazel, then clone the canonical repository with submodules and build the release target: `git clone --recurse-submodules https://gerrit.googlesource.com/gerrit` followed by `cd gerrit && bazel build release`. ### What does the release counter in the Gerrit package version mean? It is a counter that starts at 1 and indicates how many packages have been released with the same version of the software. On Debian and Ubuntu the install is `apt-get install gerrit=-`, on CentOS and RedHat it is `yum install gerrit-[-]`, and on Fedora `dnf install gerrit-[-]`. ### Are there official Gerrit Docker images? Yes, on DockerHub under the gerritcodereview user, with a CentOS 8 based image and an Ubuntu 20.04 based image, each mapping port 8080. The release suffix in the tag is optional, and when it is omitted the last released package of that version is installed. ## Sources - [GerritCodeReview/gerrit on GitHub](https://github.com/GerritCodeReview/gerrit) - [Issues](https://github.com/GerritCodeReview/gerrit/issues) - [License: Apache-2.0](https://github.com/GerritCodeReview/gerrit/blob/master/LICENSE) - [README](https://github.com/GerritCodeReview/gerrit/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gerritcodereview-gerrit