Pull requests and code review

How a team gets your branch into main · 8 min

In one breath

A pull request (PR) is a GitHub feature, not a git command: "here's my branch, please review it and merge it into main". Teammates read the diff, comment, and approve. Automated checks (CI) build and test it, and then it's merged. Nobody pushes straight to main.

The workflow, start to finish

git switch main → git pull: start from the latest.
git switch -c fix/weapon-map-uproperty: your own branch.
Work, add, commit, in small clear commits.
git push -u origin fix/weapon-map-uproperty. -u remembers the link, so later it's just git push.
Open the PR on GitHub (it offers a button after you push), or gh pr create from the terminal.
Review: teammates comment on lines; you answer, push more commits to the same branch, and the PR updates itself.
CI (automated build and tests) goes green.
Approved → merge → delete the branch.

The name is confusing: you're asking them to pull your branch in. GitLab calls the same thing a merge request, which is clearer.

Three ways GitHub can merge it

Button	Result on main	Teams pick it when
Create a merge commit	All your commits + a merge commit	They want the full history of how the work happened
Squash and merge	Your whole branch becomes one commit	They want one tidy commit per feature (very common)
Rebase and merge	Your commits replayed onto main, no merge commit	They want a straight-line history

It's a team setting. Just follow whatever the repo does.

Writing a PR people want to review

Small. 200 lines gets a careful review; 2,000 gets "LGTM" ("looks good to me") and bugs. Split big work into several PRs.
Title like a commit subject. Description: what, why, how you tested it, screenshots or a GIF for anything visual (very welcome in games).
Review your own diff first on GitHub's "Files changed" tab. You'll catch half the comments before anyone else does.
Answer every comment: fix it, or explain why not. "Done" is fine. Arguing in comments isn't. Take long discussions to a call.

Reviewing someone else's

Comment on the code, not the person: "this pointer can dangle if…" not "you forgot…".
Ask questions when unsure: "Is there a reason this isn't a UPROPERTY?" You might learn something.
Mark nitpicks as nitpicks ("nit: typo in category name") so they don't block the merge.

Interview tie-in

"How do you verify your work?" (your mock Q2) and "how do you take feedback?" both have a PR answer: "I review my own diff before asking anyone, keep PRs small enough to review properly, and treat review comments as free bug-finding." You already end each plugin Part with a whole-branch review and fix the findings in their own commits. That's the same habit.

Quiz yourself

Is a pull request a git feature?

No. It's a hosting-site feature (GitHub; GitLab calls it a merge request) built on top of branches.

List the steps from "start a fix" to "it's in main".

Pull main → new branch → commits → push the branch → open PR → review and fixes → CI passes → merge → delete branch.

Reviewer asks for a change. Do you open a new PR?

No. Commit to the same branch and push, and the PR updates automatically.

Squash and merge: what does main end up with?

One single commit containing the whole branch's changes.

Why keep PRs small?

Small diffs get careful reviews. Huge ones get skimmed and approved with bugs in them.

What does -u do in git push -u origin my-branch?

Sets the upstream link, so later plain git push / git pull on that branch know where to go.

What should a PR description include?

What changed, why, how it was tested, and screenshots or GIFs for anything visual.