What it is: Code review is the practice of having one or more other people read and evaluate a proposed code change before it becomes a permanent part of a project. Instead of a developer changing code and immediately making it official, the change is paused, shown to teammates, discussed, possibly revised, and only then accepted.

Why it exists: No single person — no matter how experienced — reliably catches every bug, security hole, or confusing piece of logic in their own work. A second reader, seeing the code with fresh eyes and without the author’s assumptions, regularly spots problems the author missed. Code review turns “one person’s best effort” into “the team’s collective judgment.”

Where it’s used: Code review is standard practice at nearly every serious software company and open-source project, from two-person startups to organizations with thousands of engineers. In Git specifically, it’s most commonly organized around a mechanism called a pull request (also called a “merge request” on some platforms), which we’ll unpack in Chapter 3.

Practical example: At a company building a mobile banking app, a developer might fix a bug in how account balances are calculated. Before that fix goes live, a teammate reviews the change, notices the fix doesn’t handle a specific currency-rounding edge case, and asks for it to be corrected — catching a bug that could have caused real customers to see wrong balances.

In the earliest days of software development, a single programmer often wrote, tested, and shipped code entirely alone. As teams and codebases grew larger through the 1970s and 1980s, companies noticed a pattern: bugs that slipped into production were disproportionately the kind that a second person would have caught in seconds — a typo in a condition, a forgotten edge case, a security check left out. Formal “code inspections,” pioneered at IBM in the 1970s, showed that structured review by peers caught a large share of defects far more cheaply than finding them after release.

Version control systems like Git made this practice dramatically easier to adopt at scale. Because Git lets a developer create an isolated branch — a separate line of work that doesn’t touch the shared codebase — a team can build a workflow where no code reaches the shared branch without first being reviewed on its own branch. This is the technical foundation that platforms like GitHub built pull requests on top of.

The core problem code review solves: individual engineers have blind spots, incomplete context, and inconsistent standards. Left unchecked, this leads to bugs, security vulnerabilities, inconsistent code style, and knowledge locked inside one person’s head. Code review distributes both the checking and the knowledge across the team.

In Git, a branch is an independent line of development — think of it as a parallel copy of the project where you can make changes without affecting the main, shared version (often called main or master). A developer working on a new feature or bug fix typically creates a new branch, makes their changes there, and commits them — all without touching the main branch at all.

Once the work on that branch is ready, the developer opens a pull request: a formal request asking the team to review the changes on their branch and, if approved, merge (combine) them into the main branch. The pull request is the container where the entire review conversation happens.

flowchart LR
    A["Developer creates a branch"] --> B["Commits code changes to the branch"]
    B --> C["Opens a Pull Request"]
    C --> D["Reviewers read the diff and comment"]
    D --> E{"Changes requested?"}
    E -->|Yes| F["Author updates the branch"]
    F --> D
    E -->|No, approved| G["Pull Request is merged into main branch"]
    

Step by step, in plain language: first, the author isolates their work on a branch, so nothing they do can accidentally affect the shared codebase yet. Second, they push that branch to the shared remote repository and open a pull request, which automatically shows a “diff” — a side-by-side view of exactly which lines were added, removed, or changed. Third, one or more reviewers read that diff and leave comments, either on specific lines or on the pull request as a whole. Fourth, if reviewers ask for changes, the author makes more commits on the same branch, and the pull request updates automatically to show the new changes. Fifth, once reviewers are satisfied, they formally approve the pull request. Finally, the approved changes are merged into the main branch, becoming a permanent, shared part of the project.

Not every review needs to check all eight dimensions with equal depth — a one-line documentation fix mostly needs a readability check, while a change to a payment system deserves careful attention to correctness, testing, and security. Experienced reviewers calibrate how much scrutiny a change needs based on its risk and size.

The Small, Focused Pull Request changes one thing, is easy to describe in a sentence, and can typically be reviewed in under fifteen minutes. This is the gold standard: small changes get reviewed faster, more thoroughly, and with fewer misunderstandings.

The Required-Approval Workflow configures the repository so that a pull request cannot be merged until at least one (often two) reviewers have formally approved it. This is the most common safeguard used by teams to make sure review isn’t accidentally skipped under deadline pressure.

The Automated-Checks-Plus-Human-Review Workflow pairs human review with automated checks — tests, linters, and security scanners — that must all pass before a human even needs to look at the change, freeing reviewers to focus on judgment calls rather than mechanical issues like formatting.

The Pair-Programming Alternative is worth mentioning: some teams write code together in real time instead of reviewing afterward, treating the “review” as continuous rather than a separate step. This isn’t better or worse than pull-request review — it’s a different way of getting a second set of eyes on the work.

Common anti-patterns to avoid: the Rubber Stamp (approving without truly reading the change, just to unblock a teammate); the Nitpick Avalanche (burying a pull request in dozens of minor style comments while missing a real correctness bug); and the Silent Reviewer (a reviewer assigned to a pull request who never responds, leaving the author blocked indefinitely).

Security-conscious teams treat certain kinds of changes — authentication logic, payment handling, access-control rules, anything touching user data — as requiring mandatory review from someone with security expertise, not just any available teammate. Some organizations enforce this automatically: a repository can be configured so specific file paths always require a specific reviewer or team, regardless of who wrote the change.

Review also acts as a check against a specific, well-documented risk called a supply-chain attack, where a contributor (or a compromised account) tries to sneak malicious code into a project disguised as a legitimate, helpful change. Careful review of what a change actually does — not just what its description claims — is one of the few defenses against this kind of attack. Payment handling, authentication, and access-control changes deserve this level of scrutiny most of all.

Finally, most platforms let teams require that reviews come from someone other than the change’s author — a rule usually called requiring “review from a different person,” which exists specifically so a single compromised or careless account cannot approve its own risky changes.

Common mistakes beginners make: taking review comments personally instead of as feedback on the code; approving a pull request without actually running or reading it carefully because a teammate seems trustworthy; and, as an author, responding defensively to comments instead of asking clarifying questions when feedback is unclear.

The core trade-off to internalize is this: code review trades a small, predictable delay now for a much larger, unpredictable cost avoided later — the cost of a bug, security incident, or unmaintainable code discovered after release. Teams that skip review to move faster in the short term often pay for it with slower, riskier changes down the line.