Git pull request: what it is and how to create a PR on GitHub

A pull request (PR) is a proposal to merge changes from one branch into another, handled on a platform such as GitHub. You push a branch to the server, open a PR, and the team sees the diff, comments on lines, runs automatic checks and only then clicks the merge button. GitLab calls the same mechanism a merge request (MR). In short, a git pull request is the control point between "I wrote the code" and "the code reached main."

What a git pull request is and where the name comes from

The name grew out of history. The author of changes asks the repository owner to "pull" their branch into the main one, which gives "pull request." GitLab chose to name it after the result, merge request, a request to merge. Bitbucket and Azure DevOps use the term "pull request." In essence it is the same thing: a source branch, a target branch, a description, discussion, checks and a merge button.

It is important to understand that a pull request is not part of Git. Git itself has no "PR" object. You cannot create it with a commit or find it in the .git folder. It is an entity of the platform. GitHub stores the description, the comments and the check statuses itself, while Git handles only the branches and commits that the PR includes.

In developer conversations, "PR" almost always means pull request: "send me the PR," "PR for review," "I merged the PR." For GitLab people say MR.

Pull request and git pull: the difference

These two things are constantly confused because the words are similar. The git pull command downloads new commits from a remote repository and immediately merges them into your current branch. It is a local operation in the terminal. A pull request is a web page on GitHub with a proposal to merge one branch into another.

There is no separate "git pull request" command in Git. There is an old utility, git request-pull, but it only generates the text of an e-mail with a summary of changes for a mailing list. It has nothing to do with PRs on GitHub.

Why pull requests are needed

While a project has one person, you can commit straight to main. As soon as the repository has two or more people, direct pushes to the main branch become a source of broken builds and lost work. A pull request solves several problems at once:

• code review — a second person sees the changes before they reach main and catches mistakes the author missed;
• automatic checks — GitHub Actions or another CI runs tests and linters on every PR, and a red status stops broken code from being merged;
• a history of decisions — a year later, a PR shows not only what was changed but also why, with the discussion;
• contributing to other projects — in open source you have no write access, and a PR from a fork is the only way to propose a fix;
• branch protection — GitHub branch protection rules can forbid direct pushes to main and require an approved PR.

How to create a pull request on GitHub from a branch

This is the main workflow for a team where everyone has write access to the repository. You work in a feature branch, and main changes only through a PR.

Step 1. Create a branch from an up-to-date main

git switch main
git pull
git switch -c feature/login-form

Make the branch name descriptive: feature/…, fix/…, or a task number. The reviewer immediately knows what it is about.

Step 2. Make commits

git add src/login.js
git commit -m "Add login form"

One PR, one task. A small PR of 100–300 lines is reviewed quickly and carefully. With 3000 lines, the reviewer approves without really looking.

Step 3. Push the branch to the server (git push for a pull request)

git push -u origin feature/login-form

The -u flag links the local branch with the remote one, so a plain git push is enough from then on. In its reply, GitHub suggests a link for creating the PR:

remote: Create a pull request for 'feature/login-form' on GitHub by visiting:
remote:      https://github.com/team/app/pull/new/feature/login-form

Step 4. Open the PR in the web interface

Follow the link from the terminal, or open the repository on GitHub. After a fresh push, a banner with a "Compare & pull request" button appears there. Another way is the "Pull requests" tab and the "New pull request" button.

1. Check the pair of branches: base is where you merge into (usually main), compare is your branch.
2. Write a title: what has been done, in the imperative mood or as a short description.
3. In the description, explain why, how to test it, and what is left out of scope. If the repository has a PR template, the fields are filled in automatically.
4. On the right, assign reviewers, an assignee and labels if your team uses them.
5. Click "Create pull request," or choose a draft (more on that below).

Creating a PR from the terminal: GitHub CLI

If you do not want to switch to the browser, there is the official gh tool. It is not a Git command but a separate GitHub program, and it is convenient for PRs:

gh pr create --base main --title "Add login form" --body "Closes #42"
gh pr list
gh pr checkout 57
gh pr merge 57 --squash

To the question "which git commands are used for pull requests," the honest answer is this: Git handles branches, commits and push, while the PR itself is created on the platform, in the browser, through gh or the API.

How to make a pull request to someone else's repository through a fork

In open projects you have no write access. So you first make a fork, your own copy of the repository on GitHub. You work in that copy and propose changes to the original.

1. On the project page, click "Fork." You get github.com/you/project.
2. Clone your fork and add the original as a second remote, usually named upstream.
3. Create a branch, make commits and push the branch to your fork.
4. On GitHub, open the PR: base repository is the original project, head repository is your fork and your branch.

git clone git@github.com:you/project.git
cd project
git remote add upstream https://github.com/owner/project.git
git switch -c fix/typo-readme
git commit -am "Fix typo in README"
git push -u origin fix/typo-readme

Before you start, look at the CONTRIBUTING.md file. It usually describes commit rules, tests and whether you should open an issue first. Keep the fork up to date: run git fetch upstream and git rebase upstream/main in your branch, so the PR does not fall behind the original.

Merge request in GitLab: what it is and how to create one

A merge request in GitLab is a full equivalent of a pull request. The names and some interface details differ, but the process is the same: branch, push, merge request, review, merge.

You can create an MR in several ways:

• through the link GitLab prints in the terminal after you push a new branch;
• in the Merge requests section of the project, with the "New merge request" button, choosing the source and target branches;
• right during push, using GitLab push options, without opening a browser.

git push -o merge_request.create -o merge_request.target=main origin feature/login-form

GitLab uses slightly different terms: approval is called approve, the person responsible for the merge is the assignee, and GitLab CI/CD with the .gitlab-ci.yml file works instead of GitHub Actions. Drafts exist too. They are called Draft.

Reviewing a pull request

The reviewer opens the "Files changed" tab and sees the diff. You can leave a comment on any line or suggest a ready-made edit (a suggestion), which the author applies with one click. Comments are collected into a review and sent together with one of the verdicts:

• Comment — remarks without a decision;
• Approve — the changes are approved;
• Request changes — more work is needed, and merging is not recommended.

A good review looks at logic, readability, tests and edge cases. It does not argue about taste. Leave formatting to a linter in CI. The author should reply to every comment: fixed it, discussed it, or left it as is with an explanation.

How to check someone else's PR locally (git checkout a pull request)

Sometimes you need to run the code yourself. If the branch lives in the same repository, git fetch and git switch are enough. For a PR from a fork, GitHub provides special references pull/<number>/head:

git fetch origin pull/57/head:pr-57
git switch pr-57

In GitLab, the equivalent references are called merge-requests/<number>/head. Or simply run gh pr checkout 57 if you have the GitHub CLI.

How to update a pull request after review comments

A PR is tied to a branch, not to specific commits. Just make new commits in the same branch and push them. The PR updates itself, and you do not need to create a new request.

git commit -am "Address review comments"
git push

Git rebase for a pull request: bringing in a fresh main

While a PR waits for review, main moves ahead. If GitHub says the branch is outdated or has conflicts, update it. The rebase option gives a linear history:

git fetch origin
git rebase origin/main
# resolve conflicts, git add, git rebase --continue
git push --force-with-lease

After a rebase the commit hashes change, so a regular push is rejected. You need a forced push. Use --force-with-lease: it refuses to overwrite the branch if someone else's commits have appeared in it. If more people than you work in the branch, it is safer to bring in main with git merge origin/main, which does not rewrite history.

How to merge a pull request: merge, squash and rebase

When the review is approved and the checks are green, you can merge the PR. GitHub offers three ways, and a repository administrator can allow only some of them.

Merging a PR through the interface is essentially the same git merge, just run on the server. After the merge, GitHub offers to delete the branch. Agree, because it is no longer needed. Clean up locally too:

git switch main
git pull
git branch -d feature/login-form

You can also merge a PR manually from the terminal: merge the branch into main locally and push it. GitHub notices that the branch's commits reached the base and marks the PR as merged on its own. But this skips the checks and the branch protection rules, so teams usually merge with the button.

Auto-merge and merge queue

If checks take a long time, you can turn on auto-merge. The PR merges by itself when all conditions are met. Large repositories use a merge queue, which tests each PR on top of the PRs already in the queue, so that main does not break because of incompatible changes.

Draft pull requests

A draft is a PR that is not ready for review yet. It cannot be merged, and reviewers do not get a request to check it. Drafts are useful for showing a direction early, running CI, or collecting opinions on the architecture. On GitHub, choose the draft option in the drop-down menu of the create button when you open the PR, or run gh pr create --draft. When the work is ready, click "Ready for review." In GitLab, a draft is marked with a Draft: prefix in the MR title.

Linking a pull request to issues

If you write a keyword and an issue number in the PR description, GitHub closes the issue automatically after the merge into the default branch:

Closes #42
Fixes #17
Resolves #8

The words close, fix and resolve work in their various forms (closes, fixed, resolves). A mention of #42 without a keyword only creates a link and does not close the task. GitLab works the same way with Closes #42 and similar phrases.

Can you delete a pull request or a merge request?

An ordinary participant cannot delete a PR on GitHub. They can only close it with the "Close pull request" button. A closed PR stays in the history, and you can reopen it. Delete the branch separately after closing. A PR can be fully deleted only through GitHub Support, for example if secrets ended up in it.

In GitLab, an MR can be closed by its author or by a participant with the right permissions. Deleting it is for the project owner or an administrator. If a password or token got into a PR, closing it is not enough. Revoke the secret right away, because the commits were already on the server.

Common pull request mistakes

• A PR from main. You committed to your own main and opened a PR from it. The next PR will include the old changes too. Always work in a separate branch.
• Wrong base branch. The PR is opened into develop instead of main, or the other way around. You can change the base with the Edit button next to the PR title.
• Extra files in the diff. Build output, node_modules, .env. Add them to .gitignore and remove them from the index with git rm --cached.
• A huge PR. Split the task into several consecutive PRs.
• A plain push after a rebase. The error rejected (non-fast-forward). You need git push --force-with-lease, not --force.
• Conflicts. Do not resolve them blindly in the web editor. Bring main in locally, resolve the conflicts and run the tests.

Pull requests in git flow and other workflows

A pull request fits into any team process. In GitHub Flow everything is simple: a branch from main, a PR, review, merge, deploy. In git flow, PRs are opened into develop from feature branches, and release and hotfix branches also go through a PR into main. In trunk-based development, PRs are short and live for hours rather than days. Whatever the process, the rule is the same: changes to shared branches go only through a pull request.

Summary

A pull request is a platform mechanism, not a Git command. It is a branch pushed to the server plus a page with discussion, review and checks. On GitLab it is a merge request. In everyday speech people say PR and MR. Create PRs from a separate branch, keep them small, update them by pushing to the same branch, and pick a merge method that suits your project's history. Feature branches, forks and pull requests are covered hands-on in our Git course.