Pull requests and code review
Show me first
Kai finished bouncy lasers on a branch, a separate line of commits (save points) that keeps main safe. Before merging it (combining it into another branch), Kai opens a pull request, or PR: "here are my changes, please check them before they go in".
Teammates reading each other's changes is called code review. Many professional teams require at least one review before any change is merged. Even the best developers miss their own mistakes.
Opening a PR
Kai pushes the branch (uploads its commits to GitHub), then clicks Compare & pull request. A good PR has:
- Base and compare branches: where the changes go, and where they come from.
- A title: "Add bouncy lasers".
- A description: what changed, why, and how to test it.
- Reviewers: who should check it, here Remy.
Writing Closes #12 in the description links task card #12. When the PR is merged into main, GitHub closes the card by itself.
Quick check
What should a pull request description say?
- What changed, why, and how to test it
- The team's passwords, so reviewers can log in
- Nothing, the code explains itself
Show the answer
What changed, why, and how to test it
The description helps the reviewer understand and test the change quickly. Passwords never belong in a PR, and code alone doesn't say why a change was made.
Reviewing a PR
Remy opens the PR's Files changed tab. It shows a diff of every file: removed lines with a minus, added lines with a plus. Remy can click any line to leave a comment. Then Remy plays the branch and submits a review:
- CommentFeedback only, no decision yet.
- ApproveReady to merge. Reviewers often write LGTM: looks good to me.
- Request changesSomething must be fixed before this can be merged.
Changes requested
Remy requests changes: "Lasers bounce forever and the screen fills up. Can they stop after 3 bounces?"
Kai doesn't open a new PR. Kai fixes it on the same branch, commits and pushes. The new commit appears in the PR automatically, and Remy reviews again.
Good review comments are about the code, not the person, and they say why. "This loop runs every frame, so it might slow phones down" beats "this is bad".
Review reply
The bounce limit is typed straight into the code as 3. Could it live in balance.json, so we can tune it without changing code?
What should Kai do?
- Move the number into balance.json, then commit and push to the same branch
- Close the PR and start again on a new branch
- Merge anyway, the lasers already work
Show the answer
Move the number into balance.json, then commit and push to the same branch
It's a fair request with a clear reason. Fixing it on the same branch adds the commit to the same PR, so Remy can review it again right there.
Checks on the PR
Every PR also gets checks. A robot called GitHub Actions runs our automated tests, tiny programs that check the code does what it should. A green tick means they passed. A red cross means something failed.
Repos can have branch protection rules, like "main needs 1 approval and passing checks". The merge button stays locked until both are true. Our studio uses exactly that rule for main.
Reviewing AI-written code
- Only what was askedDoes the diff touch files nobody asked about?
- Honest testsWere tests deleted or weakened just to turn the tick green?
- No secretsNo passwords or keys pasted into the code.
- Play itRun the branch and play the part that changed.
AI agents can open PRs too. Review them like a teammate's, only more carefully: AI code can look neat and still be wrong.
Review the AI
1score.js2- score = score + n;3+ score = score + n * combo;4 5score.test.js6- test('hit adds 10 points', ...);7+ // removed old test
An AI agent opened this PR, and all checks are green. What should the reviewer notice?
- A test was deleted instead of the code being fixed, so the green tick proves less than it seems
- Nothing, green checks mean it's safe to merge
- The file names are too short
Show the answer
A test was deleted instead of the code being fixed, so the green tick proves less than it seems
The old test probably failed because combo was not set. Deleting a failing test hides the bug instead of fixing it. Ask for the test back, and for combo to start at 1.
Merge options
- Create a merge commitKeeps every commit from the branch and adds one commit that joins the two lines.
- Squash and mergeSqueezes all the branch's commits into one tidy commit. Great when the branch has 15 commits called "try again".
- Delete the branchIts work is merged now, so GitHub offers a button to delete it.
Bolt says: Next lesson: docs and READMEs, so every change explains itself. Then the automated tests behind those checks.
Fact-checked 9 October 2026
- GitHub Docs: Reviewing proposed changes in a pull request docs.github.com
- GitHub Docs: About protected branches docs.github.com
- GitHub Docs: Merging a pull request docs.github.com
- GitHub Docs: Linking a pull request to an issue docs.github.com