Pull requests and code review

A pull request (PR) — called a merge request on GitLab — is how a team actually gets work into main. It is a proposal: "here is a branch of changes; please review it, and if it is good, merge it." Around that simple idea sits most of professional software collaboration: code review, automated checks, discussion, and the gate that keeps main healthy. As a DevOps person you will open PRs, review them, and wire up the checks that run on them. This lesson is pull requests and code review.

What a pull request is

You have your work on a branch (the branching lesson). Rather than merging it into main yourself, you push the branch and open a pull request against main. The PR shows the diff — every change your branch makes — and gives the team a place to:

• Review the changes and comment on specific lines.
• Run automated checks (CI — the CI/CD module): tests, linting, a build, all on your branch before it can merge.
• Discuss and request changes, which you address with more commits on the same branch (the PR updates automatically).
• Approve and merge once it is good.

So a PR turns "I merged my code" into "the team agreed this code is good, the checks passed, and then it merged." That gate is the whole point: it keeps main reviewed, tested and deployable, instead of whatever one person happened to push.

Why review matters

Code review is not bureaucracy; it does real work that nothing else does:

• It catches bugs a second pair of eyes sees and the author, close to the code, missed.
• It spreads knowledge — reviewers learn what changed, so no part of the system is understood by only one person (a real risk when someone leaves or is on leave).
• It keeps quality consistent — style, patterns, and standards stay coherent across a team instead of drifting per person.
• It creates a record — the PR discussion is a durable explanation of why a change was made, invaluable months later.

A team that reviews well ships better software and has fewer "how does this even work?" moments. Review is one of the highest-leverage habits in engineering, and a PR is the mechanism that makes it routine.

Writing a PR that gets reviewed well

A good PR is easy to review, and that is largely the author's job:

• Keep it small and focused. A PR that does one thing is reviewed quickly and carefully; a giant PR touching everything gets a rubber-stamp "looks fine" because nobody can actually hold it all in their head. Small PRs get better review and merge faster.
• Write a clear description — what changed, why, and how you verified it. The reviewer should not have to reverse-engineer your intent from the diff.
• Make each commit meaningful, with messages that say what and why (not "fix" and "stuff").
• Ensure the checks pass before asking for review — do not make a reviewer discover your tests fail.
• Respond to feedback by pushing more commits and replying to comments; the conversation resolves, then it merges.

The reviewer's side matters too: review the code, not the person; be specific and kind; distinguish "this is a bug" from "I would prefer"; and approve when it is good enough, not when it is perfect (the collaboration lesson from any team course applies). A healthy review culture is fast, factual and blame-free.

Merging, and protecting main

When a PR is approved and its checks are green, it merges into main. Teams usually configure branch protection on main so that:

• PRs are required — you cannot push directly to main, only merge via a reviewed PR.
• Checks must pass — the CI must be green before the merge button works (the required-status-check idea from the QA course).
• At least one approval is needed.

This is what actually keeps main safe: not discipline alone, but a rule that unreviewed, untested code cannot get in. Teams also choose how the merge is recorded — a merge commit (keeps every branch commit), a squash (combines the branch into one tidy commit on main — common, keeps history clean), or a rebase. Squash-merging is popular because it keeps main's history readable, one commit per PR.

Check your work

A pull request proposes merging a branch into main: it shows the diff and provides review (line comments), automated checks (CI on the branch), discussion/requested changes (addressed with more commits), and approve-then-merge. It turns "I merged my code" into "reviewed, tested, agreed, then merged" — the gate that keeps main deployable.

Review does real work: catches bugs (second pair of eyes), spreads knowledge (no single-owner code), keeps quality consistent, and records why a change was made. One of the highest-leverage engineering habits.

Write reviewable PRs: small and focused (better review, faster merge), a clear description (what/why/how verified), meaningful commits, checks passing before review, responsive to feedback. Reviewers: critique the code not the person, be specific and kind, approve at "good enough".

Protect main: branch protection requires PRs (no direct push), passing checks, and approval — a rule, not just discipline. Merge style: merge commit (keeps all), squash (one tidy commit per PR — common), or rebase.

Practice

1. Push a branch and open a pull request against main; read the diff view and add a comment on a line.
2. Write a clear PR description for a change: what, why, and how you verified it.
3. Explain three concrete things code review accomplishes that testing alone does not.
4. Take a large hypothetical PR and describe how you would split it into smaller, focused ones.
5. Explain what branch protection enforces on main and why a rule beats relying on discipline.
6. Compare merge-commit vs squash merging and say why squash keeps main's history readable.

Official documentation

• GitHub — About pull requests — What a PR is and how it works.
• GitHub — About protected branches — Requiring reviews and passing checks before merge.
• Google — Code review developer guide — How to review code well, from both sides.

Next: undoing things — reset, revert and reflog.