Gerrit vs GitHub: what each review model gets right

Gerrit vs GitHub is one of the longest running arguments in code review, and it stays interesting because the two tools disagree about what a review even is. GitHub reviews a branch. Gerrit reviews a commit, and keeps every revision of it. From that one difference flow most of the practical consequences: how iteration is tracked, how approval works, and how much ceremony a contributor has to learn. Both models are defensible. The right question is which failure you would rather live with.

Two units of review: change vs branch

In Gerrit, the unit of review is a change: per the Gerrit user guide, a change consists of a Change-Id, metadata like owner and target branch, one or more patch sets, comments, and votes, where each patch set is a git commit. Authors push commits for review to a special refs/for/<branch> namespace, which is how Gerrit distinguishes review uploads from direct pushes. GitHub’s unit is the pull request: a branch containing however many commits, compared against a base branch, with reviews and threads attached to the whole. The Gerrit project describes its patch based workflow as closer to the mailing list model used by Git itself and the Linux kernel, and that lineage shows: one commit, iterated until it is right.

Where Gerrit shines: patch set lineage

When an author reworks a Gerrit change, the amended commit becomes the next numbered patch set on the same change, keyed by its Change-Id. Nothing is overwritten; the iteration history sits alongside the review. That is a native answer to the interdiff problem: a returning reviewer reads what changed since their last pass instead of re-reading the whole diff, which on GitHub takes deliberate workarounds and degrades badly under force pushes. The user guide also notes that after a rebase, reviewers see the delta against the current target branch HEAD, so lineage survives even as the base moves. The second quiet advantage is size discipline: because the unit of review is one commit, the model itself pushes toward small, atomic changes rather than relying on reviewers to ask for them.

Scored labels and submit rules

GitHub approval is close to binary: approve, comment, or request changes, with branch protection deciding how many approvals are enough. Gerrit votes on labels with scores, and the submit rule is explicit: a change can only be submitted when it has the highest value on each review label and no veto vote at the lowest value. In the default setup, as of this writing, the Code-Review label runs from a blocking low score to the familiar +2 that permits submission. Projects can define custom labels and custom submit rules, which turns merge criteria from convention into configuration: a Verified label fed by CI, a sign-off label for a security team, and so on. GitHub can approximate much of this with required status checks and CODEOWNERS, but in Gerrit the gate is the data model rather than an overlay.

Where GitHub wins: everyone is already there

The case for GitHub is not mechanical, it is gravitational. Nearly every developer you hire or attract as a contributor already knows the pull request flow, while Gerrit asks them to learn Change-Ids, refs/for pushes, and amend driven iteration before their first upload. The ecosystem gap compounds: Actions, apps, integrations, and a decade of tooling assume PRs. Gerrit is not without an ecosystem; the project advertises a plugin architecture with over a hundred community plugins and a REST API, and it anchors some of the largest review installations anywhere, with Android, Chromium, and Qt among its flagship users. But those are organizations that chose review rigor over onboarding ease and staffed accordingly. For an open source project that lives on drive-by contributions, that trade usually points the other way.

Gerrit vs GitHub: how to choose

Pick Gerrit if your bottleneck is review rigor: you want enforced small changes, explicit submit criteria, and first-class re-review, and you can afford the onboarding tax, as Android and Chromium evidently can. Pick GitHub if your bottleneck is participation: external contributors, fast hiring ramp, ecosystem leverage. Research on review at scale, including Google’s study of its internal tool Critique, suggests the process around the tool matters more than the tool: small changes, fast turnaround, and clear expectations are what make review work. Gerrit encodes those norms in software; on GitHub you supply them as culture and tooling. (Disclosure: we build Pyor, a review client for GitHub pull requests, so we live on the GitHub side of this fence.)

There is also a middle path worth knowing about before you commit either way: the Gerrit project points to GerritHub.io, a hosted service that runs Gerrit review on top of GitHub repositories. It lets a team keep its code and contributors where they are while trialing the patch set workflow on real changes, which is a far better evaluation than any comparison table, this one included. If the lineage and the submit rules earn their keep in that trial, migrate deliberately. If they do not, you have learned which discipline you were actually missing, and that discipline can usually be rebuilt on the platform you already have.