What is a pull request?

What is a pull request?

A pull request is a request to merge the commits on one branch into another branch, where people and tools check them first. It shows the diff, the lines the change adds and removes, next to review comments and the results of automated checks. It is often shortened to PR, and GitLab calls it a merge request.

The name describes the request, which asks a maintainer to pull the commits in. In Git, a pull fetches commits from another repository and integrates them into the current branch. The git request-pull command prints such a request as text. A code host, e.g. GitHub, turns the request into a page with its own review and checks.

Pull requests are where teams on a code host usually do code review.

How does a pull request work?

On GitHub, the pull request workflow takes a change from a branch to a merge in six steps:

1. The author creates a branch from main and commits the change to it.
2. The author pushes the branch and opens a pull request between the head branch, which holds the change, and the base branch, which receives it.
3. GitHub shows the diff and prepares a trial merge, so checks can run on the combined code without changing the base branch. A merge conflict, often from both branches changing the same lines, blocks the merge until someone resolves it.
4. The checks run, and reviewers comment on lines of the diff, then approve or request changes.
5. The author pushes more commits, and the checks run again.
6. A person with write access merges the change with a merge commit, as one squashed commit, or by rebasing each commit onto the base branch.

GitLab merge requests follow similar steps, with a source branch and a target branch. In open-source projects, a contributor without write access usually opens the pull request from a fork, a copy of the repository under the contributor's account.

The checks usually come from a workflow that runs the tests, e.g. one in GitHub Actions. Required status checks are the results that must pass before a pull request can merge into a protected branch.

A draft pull request lets an author share work early. It cannot be merged, and GitHub does not request reviews from code owners until the author marks it ready.

What is an example of a pull request?

Here is an illustrative example. Acme Co. sells furniture online. A developer at Acme asks a coding agent to "Let customers edit their delivery address during checkout." The agent commits the change on a branch called address-edit, pushes it, and opens a pull request against main:

gh pr create --base main --head address-edit \
  --title "Let customers edit the delivery address" \
  --body "Adds an address form to checkout. Tests pass."

The pull request then goes through these steps:

1. GitHub numbers the pull request #1042, and its diff shows 2 changed files.
2. The test workflow runs on the pull request and passes.
3. A reviewer comments that no test checks the cart after the address changes.
4. The agent pushes a commit with that test to address-edit, and the checks run again.
5. The added test fails. The address saved, but the cart emptied.
6. The agent pushes a fix, the checks pass, and the reviewer approves.
7. The developer merges it as one squashed commit, so main gains a single commit that holds the whole change.

The broken change never reached main, because the reviewer's comment led to a test that failed on the pull request before the merge. This example is simplified. A real pull request often has more than one reviewer and several rounds of comments.

What changes when a coding agent writes the code?

When a coding agent writes the code, the agent can also open the pull request and generate its description. The description is where an author states what the change does, why, how it was checked, and what a reviewer should read first. An agent's description can be as thin as the one at Acme, which says only that tests pass, not which tests ran. Much of the reason for the change stays in the agent session, and a reviewer can recover intent from a saved session.

Background coding agents work on a task while nobody watches and return a branch or a pull request when they finish. GitHub's Octoverse 2025 counted an average of 43.2 million pull requests merged each month, up 23% on the year before. When agents open more pull requests than people can read, a review bottleneck forms, and a skimmed approval becomes a rubber-stamp review.

The pull request looks the same, but the account that opens it changes what an approval means. On GitHub, the author of a pull request cannot approve it, and that rule checks accounts, not people. When the agent opens the pull request under its own account, the developer who gave it the task is not the author. That developer can then give the required approval, so the change can merge without a second person reading it.

GitHub blocks that approval on pull requests from its own Copilot cloud agent. For other agents, GitHub cannot tell who gave the agent its task. The team can require two approvals, or adopt a written rule that the requester's approval does not count. That reviewer can start from the steps for reviewing agent pull requests and use a code review checklist for the diff.

What are the limits of a pull request?

A pull request holds review and checks, but it has four limits:

• An approval is not a run. Reviewers read the diff, which shows the changed lines but not the code that depends on them or what the software does. An approval with no comments does not show that the change works.
• A green check can go stale. A check tests the change against the base branch as it stood at one point, and main keeps moving. Two green pull requests can still break main once both merge. A merge queue catches that by testing each change with the changes ahead of it.
• A branch isolates code, not data. A running copy of the branch that shares a database with other branches can change their data, e.g. through a migration. Database branching can give each pull request its own copy of the database.
• Each pull request waits. A change sits until a reviewer is free, and long waits can push authors to batch work into bigger diffs. Pull request size then sets how closely a reviewer can read.

How is a pull request different from a direct commit to main?

A direct commit to main puts a change into the shared branch with no request and no review before it lands. Checks on main then run after the change is already there, so a broken commit affects everyone who pulls it until someone reverts or fixes it. A pull request adds review and checks before the merge, at the cost of waiting for them. It also keeps a record of the review next to the change, where a direct commit keeps only its message.

On GitHub, a branch protection rule that requires reviews lets collaborators change the protected branch only through an approved pull request. By default, the rule does not apply to people with admin permissions, so admins can still push to main. Teams that practice trunk-based development merge small changes into main at least once a day, through short pull requests or direct commits.

FAQs

Is a merge request the same as a pull request?

A merge request is GitLab's name for the same thing as a pull request. Both ask to merge one branch into another after review and checks. GitLab calls the two branches the source branch and the target branch, where GitHub says the head branch and the base branch.

Why is it called a pull request?

A pull request is named for the maintainer's action, not the author's. The author pushes commits to a branch or a fork, then asks a maintainer to pull them in. In Git, a pull fetches commits from another repository and integrates them into the current branch.

What is a draft pull request?

A draft pull request is a pull request that its author has marked as not ready for review. On GitHub, a draft cannot be merged, and code owners are not asked to review it until the author marks it ready for review.

Who can merge a pull request?

A pull request on GitHub can be merged by a person with write access to the repository. A contributor who opens one from a fork usually lacks that access, so a maintainer merges it. A branch protection rule can also require an approval and passing checks first.

What should a pull request description say?

A pull request description should say what the change does, why, how the author checked it, and what a reviewer should read first. A description that says only that tests pass does not say which tests ran or which behavior they check.