Pull request workflow

Git · Practical · 10 min

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, then git switch -c feature/x.
  • Make focused commits; push with git push -u origin feature/x.
  • Open the PR (web UI, or gh pr create with 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 main moved and conflicts appear, merge or rebase origin/main into 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 main linearly.

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-deleted

Remember

  • 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.

Check yourself

  1. A reviewer requests changes on your open PR. How do you update it?
  2. What does 'squash and merge' put on main?

Sign in to answer, see the explanations, and get this lesson back as a quick review later.

Official docs: git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project