Code review is the practice of having one or more developers examine a proposed change before it is merged into the shared codebase. The goal is to catch bugs early, keep quality consistent, and let team members learn from each other rather than to gatekeep for its own sake.
Gerrit’s own documentation describes the benefits plainly: a structured review process leads developers to work with greater care, absorb techniques from peers, and maintain consistent quality, with reviews evaluating design choices, functional correctness, code comprehension, naming clarity, and documentation. This echoes much older software-inspection practice, formalized here into a tool.
Modern hosting platforms turned the idea into a routine, lightweight step built into everyday workflow. GitHub’s documentation defines a pull request as a proposal “to merge code changes into a project” and calls it the platform’s “foundational collaboration feature, letting you discuss and review changes before merging them.” GitLab calls the same mechanism a merge request.
Two broad styles emerged. Gerrit’s patch-based model, used by Android and Chromium, requires explicit approval before a change can land, resembling the mailing-list review long used by the Linux kernel. The pull-request and merge-request model popularized by GitHub and GitLab made review the normal way open-source and corporate teams alike accept contributions.