Pull (merge) requests are how almost every team reviews and lands code.
A pull request (PR; GitLab calls it a merge request) is a hosting-platform feature, not a Git command: a request to merge one branch into another, with a page for discussion, review and automated checks. Under the hood it is still branches and commits.
The typical loop:
- Update
main, thengit switch -c feature/x. - Make focused commits; push with
git push -u origin feature/x. - Open the PR (web UI, or
gh pr createwith the GitHub CLI). Describe what and why, how to test it, and link the issue. - CI runs tests on the branch; reviewers comment.
- Address feedback with new commits and push again; the PR updates automatically.
- If
mainmoved and conflicts appear, merge or rebaseorigin/maininto your branch and push. - Merge, then delete the branch, locally and on the remote.
Platforms offer three merge buttons, and teams usually pick one:
- Merge commit: keeps every commit plus a merge commit.
- Squash and merge: the whole PR becomes one commit on
main. Clean history; individual commits are lost. - Rebase and merge: replays the commits onto
mainlinearly.
For open-source contributions you usually can't push to the project, so you fork it, push branches to your fork (origin) and open PRs against the original (upstream).
Keep PRs small. A 200-line PR gets a careful review in minutes; a 2,000-line one gets "LGTM".
Example
git switch main && git pull --ff-only
git switch -c feature/rate-limit
# ... commits ...
git push -u origin feature/rate-limit
gh pr create --title "Add rate limiting" --body "Limits /api to 100 req/min. Closes #42."
# Reviewer asked for changes
git commit -am "Address review: make limit configurable"
git push # PR updates
# After merge on the platform
git switch main && git pull --ff-only
git branch -d feature/rate-limit
git push origin --delete feature/rate-limit # if not auto-deletedRemember
- A PR is a platform feature around merging one branch into another
- Push new commits to the same branch to update a PR
- Merge, squash or rebase: pick one team convention
- Fork + upstream remote for projects you can't push to
Watch out for
- Piling unrelated changes into one PR — split them; reviewers and reverts both benefit.