Stop 04 · Git & Version ControlTopics · 3/8

Pull Requests & Code Review

In short

Nobody on a good team pushes straight to main. A pull request lets others read your change, and lets CI test it, before it can hurt anyone.

A pull request proposes merging one branch into another and invites review before it happens — the standard collaboration mechanism for catching issues before they reach shared code.

The mascot as an editor marks a draft page with a red pen at a busy newspaper desk.

Think of it like this

The newspaper editor's desk

A reporter writes a story, but it doesn't go to print yet. The editor reads it, checks the facts, marks a few lines in red, and the reporter fixes them. Only then does it reach the printing press. A pull request is your code sitting on the editor's desk.

Watch it happen

Life of a pull request

Open PR

CI checks

Review

Fix

Merge

1/5You push a branch and open a PR with a short description: what changed, why, and how you tested it.

The big ideas

What you need to know

Keep PRs small

A 50-line PR gets a careful review. A 2,000-line PR gets a quick 'looks good' and hidden bugs.

Write a clear description

Explain the why, link the ticket, and say how you tested. Reviewers shouldn't have to guess.

Review the code, not the person

Ask questions and suggest options: 'What if this env var is missing?' beats 'This is wrong'.

Branch protection

Settings can require approvals and passing checks before merge, so nobody skips review on a rushed day.

See it in code

Walk through the code

bash

1git switch -c feat/healthcheck2git commit -am "Add /health endpoint for load balancer checks"3git push -u origin feat/healthcheck4 5# Open the PR from the terminal with GitHub's CLI6gh pr create --title "Add health endpoint" \7  --body "Needed for the new LB. Tested with curl locally."8gh pr checks          # watch CI status9gh pr merge --squash  # after approval

1/3Create a branch, commit your change and push it to the remote.

Squash merging turns all your branch's small commits into one tidy commit on main.

Save yourself the pain

Common mistakes

Oops

Opening one huge PR that changes the pipeline, Terraform and app code together.

Do this instead

Split it into small PRs that each do one thing. They're faster to review and easier to roll back.

Oops

Approving a PR without reading it because the author is senior.

Do this instead

Seniors make mistakes too. Read the diff, run it if unsure, and ask questions.

Your mission

Review a real PR

~30 min

Quick check

Why should a team require passing CI checks before a PR can merge?

Go deeper

1Practice creating a pull request with a clear description of what changed and why.
2Learn to write and receive constructive code review comments.
3Understand why even lightweight review catches real errors before they reach production.