What is a pull request, and how to open one on GitHub

A pull request (PR) is a proposal to merge changes from one branch into another, on a page where teammates read the diff, discuss it and see automated check results before anything merges. GitHub calls the pull request its key collaboration feature, the place to discuss and review changes before merging them.

What a pull request is

The idea is older than GitHub. Git ships a git request-pull command that generates "a request asking your upstream project to pull changes into their tree," and Linux kernel maintainers still send pull requests to each other by email. A pull request on GitHub makes the same request on a web page that holds the diff, the discussion, the reviews and the check results.

GitHub's own glossary says a pull request "can be thought of as a request to merge," and GitLab names the same feature a merge request. Pull request vs merge request compares how GitHub and GitLab handle drafts, approvals, merge methods and merge trains.

A pull request is also different from a commit. A commit is a saved change to one or more files, which git records with a unique ID (its SHA). A pull request groups the commits on one branch and asks to merge them into another, so it usually holds several commits, and you can keep adding commits after you open it.

The parts of a pull request

GitHub lays these out in tabs. Conversation holds the description, timeline, comments and reviews. Commits shows how the branch changed over time, Checks shows the automated results, and Files changed shows the diff that reviewers read. A Findings tab shows automated results such as code scanning alerts. The merge status appears in the pull request header and in the merge box.

Branches

Pull requests can only be opened between two different branches. When everyone on a team can push to the repository, the head branch lives in that same repository, which GitHub calls the shared repository model. Open source projects often use the fork and pull model instead, where contributors fork the repository and open the pull request from a branch in their fork.

Title and description

The description explains the change to people who weren't there when you wrote it. It can also close issues. If the description says Fixes #123 and the pull request targets the default branch, GitHub links issue 123 and closes it when the pull request merges. The keywords are close, closes, closed, fix, fixes, fixed, resolve, resolves and resolved, and GitHub ignores them when the pull request targets any other branch.

A pull request template pre-fills every new description with the sections your team expects, such as what changed and why, how it was tested, and the risk.

The life of a pull request

Draft

A draft pull request is for work in progress that you want to share without formally asking for review. Drafts can't be merged, and GitHub doesn't automatically request reviews from code owners while a pull request is a draft.

Ready for review

When the work is done, click Ready for review in the merge box, or run gh pr ready. Marking it ready requests reviews from any code owners. You can convert a pull request back to a draft at any time, for example after feedback that needs more work, and nobody can merge it until it's marked ready again.

Review

Request reviews from the sidebar. With write access to the repository, you can ask any person or team with read access to it, and GitHub suggests reviewers based on git blame data. If the repository has a CODEOWNERS file, GitHub requests reviews from the owners of the code a pull request changes. The CODEOWNERS guide covers how to map paths to owners so the right reviewers are asked automatically.

Each review ends with one of three decisions:

• Comment: general feedback, without approving or requesting changes.

• Approve: the changes are ready to merge.

• Request changes: feedback the author should address before merging.

Two details catch people out. Request changes is informational on its own, and it only blocks merging when a ruleset or branch protection rule requires a pull request before merging. And authors can't approve their own pull requests.

Admins can go further and protect a branch so that every pull request needs a set number of approving reviews, optionally including one from a code owner. They can also dismiss approvals when new commits change the diff, or require the most recent push to be approved by someone other than the person who pushed it.

For what a good review checks, see what code review is. For the clicks involved, see how to review a pull request on GitHub.

Status checks

Status checks show whether a pull request's commits meet the conditions set for the repository. They usually come from external systems such as CI builds, tests, code scanning or deployments. GitHub Actions and other GitHub Apps create checks with detailed output and annotations, and other services can post simpler commit statuses.

If a branch requires status checks, they have to pass before the pull request can merge. One gotcha from GitHub's docs: a skipped job reports its status as "Success," so it won't block a merge even when it's a required check. To follow checks from a terminal, run gh pr checks --watch.

Merge

You need write permission to merge, and drafts can't be merged. GitHub has three merge methods, and the repository settings decide which ones are allowed:

Rebase and merge always creates new commit SHAs and updates the committer information, unlike a plain git rebase onto an ancestor commit. Squash and merge builds a default commit message you can edit, and depending on your settings it can include the pull request title, so the title can end up as the commit message on your main branch. If your team follows Conventional Commits, a format where each commit message starts with a type such as feat: or fix:, write pull request titles the same way.

GitHub can also take the waiting out of merging:

• Auto-merge merges a pull request on its own once all required reviews and status checks pass. A repository has to enable it first, and gh pr merge --auto turns it on from the terminal.

• A merge queue automates merges into a busy branch and makes sure incompatible changes never break it, without each author having to update their branch and wait for checks. It's available in public repositories owned by organizations, and in private organization repositories on GitHub Enterprise Cloud. The GitHub merge queue guide covers setup and the CI changes it needs.

Close or revert

If a change isn't needed anymore, close the pull request without merging it. If you opened it against the wrong base branch, change the base branch instead of closing it and opening a new one. After a merge, you can delete the head branch, and GitHub retargets any open pull requests that used it as their base.

If a merged pull request causes a problem, the Revert button near the bottom of the pull request creates a new pull request that reverts the original merge commit.

How to open a pull request on GitHub

If you don't have write access to a repository, fork it first and open the pull request from a branch in your fork.

In the browser

These steps follow GitHub's guide to creating a pull request:

1. Push your branch to GitHub.

2. On the repository's main page, pick your branch from the Branch menu, then click Compare & pull request in the yellow banner.

3. Set the base branch (where the changes should go) and the compare branch (where you made them).

4. Write a title and a description.

5. Click Create pull request. For a draft, open the dropdown, select Create draft pull request, then click Draft pull request.

6. Ask for reviews from the Reviewers section of the sidebar.

With the GitHub CLI

The GitHub CLI, gh, does the same from a terminal. A typical run:

git switch -c fix-login-redirect
# make your changes, then commit and push them
git add .
git commit -m "Fix redirect loop after login"
git push -u origin fix-login-redirect

gh pr create --base main --title "Fix redirect loop after login" \
  --body "Fixes #123" --reviewer monalisa --draft

git switch -c fix-login-redirect
# make your changes, then commit and push them
git add .
git commit -m "Fix redirect loop after login"
git push -u origin fix-login-redirect

gh pr create --base main --title "Fix redirect loop after login" \
  --body "Fixes #123" --reviewer monalisa --draft

git switch -c fix-login-redirect
# make your changes, then commit and push them
git add .
git commit -m "Fix redirect loop after login"
git push -u origin fix-login-redirect

gh pr create --base main --title "Fix redirect loop after login" \
  --body "Fixes #123" --reviewer monalisa --draft

gh pr create prints the new pull request's URL. A few flags worth knowing:

• --fill fills the title and body from your commit messages.

• --draft opens the pull request as a draft.

• --reviewer requests reviews from people or teams.

• --web opens the browser so you can finish there.

If you leave out --title and --body, gh prompts for them, and if your branch isn't pushed yet, it asks where to push it. Once the pull request is open:

gh pr checks --watch                   # follow CI until it finishes
gh pr ready                            # mark the draft ready for review
gh pr merge --squash --delete-branch   # squash, merge, delete the branch

gh pr checks --watch                   # follow CI until it finishes
gh pr ready                            # mark the draft ready for review
gh pr merge --squash --delete-branch   # squash, merge, delete the branch

gh pr checks --watch                   # follow CI until it finishes
gh pr ready                            # mark the draft ready for review
gh pr merge --squash --delete-branch   # squash, merge, delete the branch

Without a pull request number, these commands act on the pull request for your current branch. gh pr merge also takes --merge or --rebase for the other two methods.

How to make a pull request easy to review

Keep it small and focused

GitHub's guide to helping others review your changes says "Small, focused pull requests are easier to review and safer to merge." Google's code review guide, where a CL (changelist) is a change under review, says "100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large." It adds that small changes are reviewed more quickly and more thoroughly and are less likely to introduce bugs, and that refactoring belongs in a separate change from feature work or bug fixes. Our post on the ideal PR size covers what large pull requests cost and how to split them.

When a change can't be small, stacked pull requests split it into a chain of pull requests where each one builds on the one below, so reviewers see one layer at a time. GitHub's own stacked pull requests became generally available on October 6, 2026.

Write the description for someone who wasn't there

Say what changed, why, and where reviewers should look first. Google's guide to CL descriptions asks for a first line that's "a short summary of specifically what is being done," followed by context such as why the change is being made. Add how you tested it, screenshots for UI changes, and a closing keyword for the issue. For example:

Review your own diff first

Before you request review, read your own diff the way a reviewer would. GitHub's docs suggest checking for accidental changes and making sure the relevant builds and tests have run. A comment on lines that need context saves the reviewer a question.

Make the state obvious

Keep unfinished work in draft, and use labels to show whether a pull request is ready for review, blocked or still in progress. After you address feedback, re-request review from the same reviewer with the button next to their name in the Reviewers sidebar.

For more on cutting the time pull requests spend waiting, see how to speed up PR reviews on GitHub.

Read AI-written code before you ask for review

If a coding agent wrote the change, read the whole diff yourself before you request review. Otherwise the reviewer may be the first person who reads it.

AI-written code still has bugs. Bug Bench, our public benchmark, counts a bug when a developer upvotes a cubic review finding on AI-written code or an AI coding agent addresses it. Every one of the 7 ranked models has counted bugs, with relative bug rates from 0.65 (GPT-5.6 Sol) to 1.50 (Claude Opus 5.5), where 1.00 is the average across all AI-attributed lines. The data is observational: teams choose their models, so a rate reflects the code each model was used for as well as the model.

An AI reviewer such as cubic reviews pull requests on GitHub, finds bugs and learns your team's rules, so with AI code review your teammates start from a first pass.

FAQ

Why do we use pull requests?

A pull request gets a change reviewed before it reaches the main branch, gives the team one place to discuss it, and keeps a record of who approved what. Branch rules can require approvals and passing status checks, so changes to a protected branch can be required to go through review.

What is the difference between a PR and an MR?

Only the name. GitHub and Bitbucket call it a pull request (PR), and GitLab calls it a merge request (MR). The features around it differ, such as how each platform handles drafts, approval rules and merge queues.

Why is it called a pull request?

Because you're asking the people who own the target branch to pull your commits into it. The term comes from git, where git pull fetches changes from another repository or branch and integrates them into the current branch. A merge is the git operation that combines the two branches, and merging the pull request is what runs it once the request is accepted.

How do I check my pull requests?

On GitHub, go to github.com/pulls to see your pull requests. From a terminal, gh pr status shows the status of the pull requests relevant to you, and gh pr list --author "@me" lists the open pull requests you created in the current repository.

What is a pull request vs a commit?

A commit is a saved change to one or more files, which git records with a unique ID along with who made it and when. A pull request is a request on GitHub to merge the commits on one branch into another, with review, discussion and checks around it. One pull request usually holds several commits, and squash and merge turns them into a single commit.