Pull request and merge
- Industry term
A pull request proposes adding one branch's changes to another and gathers the changes, discussion, and automated checks for review. Merging accepts the proposal and records those changes in the target branch.
Work on a branch, a separate line of changes, leaves the project's main version untouched until the merge, so a proposal can stay open while others keep working. Git, the program that tracks changes, combines both sides' edits automatically. Where both changed the same lines, it stops at a “merge conflict,” and a person decides what stays.
Where you’ll meet it
A teammate's coding agent opens a pull request to fix a typo on your company's pricing page, and you're asked to review it. Every automatic check passes. The list of changed lines, called the “diff,” also shows an edit to the file that sets the discount for annual plans.
What to do
Hold the merge. The checks found nothing broken, and none of them asks whether the discount should change. Comment on that file in the pull request to ask why it changed, and merge once the diff covers only the typo or the discount change has been explained and approved.
Easy to mix up
| Pull request and merge | Branch |
|---|---|
| When someone merges it, or closes it unmerged | It has no finish line and lasts until it's deleted |
Check yourself
While a pull request is still open, the agent saves one more change to the same branch. What happens to the pull request?
Go deeperMerge settings and branch rules decide what review can stop
The name comes from Git's own request-pull command, which asks another maintainer to pull your branch into theirs. Hosted services such as GitHub built a review page around that request, and GitLab calls the same thing a merge request.
Each saved step on a branch is called a “commit.” A merge can keep every commit, squash them into one, or rebase them, replaying each commit on top of the target. Squashing keeps the main history short and loses the small steps. Rebasing keeps the steps in a straight line and rewrites their IDs.
Branch protection settings can require passing checks and an approving review before any merge, and a code-owners file can name who must approve changes to particular files. An agent or a hurried reviewer can't merge past them, though administrators can be allowed to. The settings can also dismiss an approval when new commits arrive, so later changes get reviewed too.