Pull Requests & Code Review: How Teams Ship

Everything in this guide has been building to one place. Commits give you a clean history; branches let you work in isolation; remotes share your work; clean history and safe undo let you shape that work with confidence. This final chapter assembles all of it into the workflow that nearly every software team on earth uses to ship: the pull request and the code review wrapped around it. This is where individual work becomes a team's shared, deliberate product.

What a pull request is

A pull request (PR) — called a merge request on some platforms — is a proposal. It says: "Here are the commits on my branch. I'd like to merge them into main. Please review them first." It bundles up your branch's changes and opens a page where your teammates can see exactly what you changed, discuss it, request tweaks, and ultimately approve the merge.

Notice what this adds on top of plain Git. Git itself will happily let you merge a branch into main with no ceremony. A pull request deliberately inserts a pause for review before that merge — a checkpoint where humans (and machines) look at the change before it becomes part of the shared code. The PR isn't a Git feature at all, strictly speaking; it's a workflow that platforms like GitHub built around Git's branches and remotes to make that checkpoint easy.

The loop, end to end

Here's the everyday workflow, drawing on every earlier chapter. It's a loop teams run many times a day.

Walk through it and notice how the whole guide shows up:

1. Branch off main — cheap isolation, from the branching chapter.
2. Commit your work in clean, focused steps — thanks to the staging area.
3. Push your branch to the remote — from the remotes chapter — so others can see it.
4. Open a pull request proposing to merge your branch into main.
5. Review happens — teammates read the diff and leave comments; automated checks run.
6. You respond — push more commits to address feedback (the PR updates automatically), maybe tidying your branch with the tools from the undo and rebase chapters.
7. Once approved, the branch is merged into main and usually deleted. Your work is now part of the shared codebase.

Then you branch again for the next thing, and the loop repeats. That rhythm — branch, PR, review, merge — is what daily life on a software team actually feels like.

Why review exists (it's more than bugs)

It's tempting to think code review is just bug-hunting, but teams that rely on it know it does more, and the extra reasons are why it's non-negotiable on most teams even when the code is fine.

• Catching defects — a second pair of eyes spots the off-by-one, the missed edge case, the security slip the author was too close to see. This is the obvious benefit.
• Spreading knowledge — when a teammate reviews your change, they learn that part of the codebase too. Review is how a team avoids having exactly one person who understands each area.
• Consistency — review keeps style, patterns, and conventions coherent across many authors, so the codebase reads like it was written by one careful person rather than twenty different ones.
• Shared ownership — once someone approved a change, the whole team owns it, not just the author. That collective accountability is healthier than lone heroes and lone blame.

Where CI fits in

Humans shouldn't waste review energy on things a machine can check. That's the job of continuous integration (CI): automated checks that run on every pull request. The moment you open or update a PR, CI kicks off — running the test suite, checking formatting, building the project — and reports back pass or fail right on the PR. If the tests break, everyone sees it before a human reviewer has to.

This is the "continuous integration runs tests every time history changes" idea from the very first chapter, now concrete. CI and human review divide the labor cleanly: machines check that it works; humans check that it's right. Many teams require both a green CI run and a human approval before a PR can merge, so nothing reaches main without passing both bars.

Keep pull requests small

One habit does more than any other to make this whole workflow pleasant: keep your pull requests small and focused. A PR that changes twenty lines to do one clear thing gets read carefully and merged in minutes. A PR that changes two thousand lines across the whole project gets skimmed, half-understood, and rubber-stamped — the exact opposite of what review is for. This is where the staging area and clean commits pay their final dividend: they're the tools that let you carve your work into small, coherent, reviewable pieces. Small PRs get better reviews, merge faster, and cause fewer conflicts. When in doubt, split it up.

Where the guide has brought you

Step back and look at what you can now do. You understand what version control is and why it exists. You know how Git stores history as content-addressed snapshots. You can branch fearlessly, merge with a clear picture of what's happening, and craft clean commits with the staging area. You can sync with a team through remotes, resolve conflicts calmly, choose between rebase and merge, and undo — or recover — almost anything. And now you can see how all of it converges in the pull-request loop that ships real software. That's not a collection of memorized commands; it's a working mental model of the tool every developer, in every role, uses every day. From here, the commands are just vocabulary for ideas you already understand.