Pull Requests and Merge Requests
On a team, nobody pushes straight to main. Instead, you ask: "Here is my branch. Please check it, and merge it if it is good." That request, and the conversation around it, is where bugs get caught and where the team learns each other's code.
The rule
Propose on a branch, check, review, then merge.
A pull request (GitHub's name) or merge request (GitLab's name) is the same idea: a proposal to merge one branch into another, usually a feature branch into main. It shows:
- the diff: every line added, removed or changed
- a description: what changed, why, and how to test it
- checks: automated jobs (CI) that run tests and linters on the branch
- reviews: teammates' comments on specific lines, and an approval or a request for changes
The whole loop, using the commands from the last two lessons:
git switch -c wishlist
# ...commit the feature...
git push -u origin wishlist
# open a pull request: wishlist → main
# reviewers comment; you fix:
git commit -am "Handle an empty wishlist"
git push # the pull request updates itselfPushing more commits to the same branch updates the open request. When the checks pass and a reviewer approves, someone clicks merge. Teams often protect main so that merging is impossible without passing checks and an approval. Some also require the branch to be up to date with main first, so the checks ran against the exact code that will ship.
Good pull requests are small and about one thing. A reviewer can think carefully about 150 lines; faced with 3,000 they tend to skim and approve.
When you review, look for correctness first (does it do what it says, including edge cases?), then safety (input validation, secrets, permissions), then clarity (names, tests, whether the next person can follow it). Comment on the code, not the person, and explain why.
The shortcut
Before opening a request, run through "Small, Described, Green": one idea, a description that tells a reviewer how to test it, and checks that pass on your machine first.
Push the branch
The wishlist commits live on
wishlist.git push -u origin wishlistputs it on the remote.
Drills
Answer fast — trust the rule.
What does GitLab call the equivalent of a GitHub pull request?
A reviewer asks for a change. How do you update your open pull request?
What do CI checks on a pull request usually do?
Which pull request is easiest to review well?
Remember
- Propose on a branch, check, review, then merge.
- Small, Described, Green before you open a request.
- Fixes go to the same branch; the request updates itself.