What Is a Pull Request? A Plain-English Guide

The short answer: A pull request is how a developer proposes changes to a project and asks teammates to review them before those changes get added to the main codebase. Think of it as "I've finished some work, here it is, please check it before we make it official." Once the team approves, the changes are merged in.

That's the core idea. Here's the plain-English version, with no coding background assumed.

What a pull request actually is

Imagine you're editing a shared company document, but instead of changing the master copy directly, you make your edits on a separate copy and then send a note to your team saying: "Here are my proposed changes. Take a look, and if they're good, fold them into the master."

That note, plus the changes attached to it, is essentially a pull request.

In software, developers don't usually add their work straight into the main project. That would be risky, since one mistake could break things for everyone. Instead, a developer does their work separately, then opens a pull request: a formal proposal that says "here's what I changed, here's why, please review it before merging."

The name comes from the underlying action: the developer is requesting that their changes be "pulled" into the main project. On GitHub it's called a pull request, often shortened to PR.

Why pull requests exist

Pull requests solve a real problem on teams: how do you let multiple people change the same project without chaos?

They allow review before changes go live. Before any code becomes part of the main project, teammates can read it, comment on it, and catch problems. It's a quality gate.

They create a discussion. A pull request has a comment thread, so the team can ask questions, suggest improvements, and agree on changes, all attached to the specific work being proposed.

They keep a record. Every pull request is saved, so there's a permanent history of what was changed, why, who reviewed it, and who approved it. Months later, you can look back and understand exactly how a decision was made.

In short, a pull request turns "one person quietly changed the project" into "the team reviewed and agreed on this change." That's a big deal for software quality.

How a pull request works, step by step

You don't need to do any of this yourself, but seeing the flow makes the concept click.

First, a developer takes the main project and makes a separate copy to work on, usually called a branch. This keeps their work isolated from everyone else's.

Second, they make their changes on that branch and save them as commits (a commit is just a saved snapshot of changes, which we explain in our plain-English commit guide).

Third, when the work is ready, they open a pull request. This bundles up all their changes and presents them for review, showing exactly what was added or removed.

Fourth, teammates review it. They read the changes, leave comments, and either request edits or approve.

Fifth, once approved, the pull request is merged, meaning the changes are folded into the main project and become official. The branch can then be closed.

So the lifecycle is: branch, commit, open the pull request, review, merge. The pull request is the review-and-approval stage in the middle.

What's inside a pull request

When you open a pull request on GitHub, you'll see a few things.

There's a title and description, where the developer explains what the change does and why.

There's the list of commits, the individual saved changes that make up the work.

There's the diff, the exact lines of code added (shown in green) and removed (shown in red).

There's the conversation, a comment thread where reviewers discuss the change.

And there are the checks, automated tests that run to confirm the change doesn't break anything. A green check means it passed; a red one means something needs fixing.

You don't need to read the code itself. The title, description, and conversation usually tell you what's going on.

Pull request vs merge request: what's the difference?

If you've seen both terms, here's the simple answer: a pull request and a merge request are the same thing. They just go by different names on different platforms.

GitHub and Bitbucket call it a pull request. GitLab calls it a merge request. The concept is identical: a proposal to review changes and combine them into the main project. GitLab argues "merge request" is the more accurate name, since the goal is to merge the changes, while "pull request" describes the underlying pull action. But functionally, they do the same job.

So if a developer on GitLab mentions a "merge request" (or "MR"), they mean exactly what a GitHub developer means by a "pull request" (or "PR").

A quick note if you're not a developer

If you manage developers rather than write code yourself, pull requests are genuinely useful to understand, because they're where you can see work happening without reading any code.

An open pull request means "a developer has finished something and it's being reviewed." A merged pull request means "that work is now part of the product." So if you want a quick read on progress, the pull requests tell a clearer story than individual commits: they're bigger, more meaningful units of completed work, each with a plain-English title and description.

That said, reading pull requests one by one still takes effort, and developers don't always write clear descriptions. If your real goal is understanding what your team is shipping without digging through GitHub, we built Shipanel to translate exactly this kind of activity into plain-English updates automatically.

Frequently asked questions

What is a pull request in simple terms? It's a developer's request to have their code changes reviewed and added to the main project. It says "here's what I changed, please check it before we make it official."

What is the difference between a pull request and a merge request? They're the same thing with different names. GitHub and Bitbucket say "pull request"; GitLab says "merge request." Both mean a proposal to review and merge code changes.

What does it mean to merge a pull request? Merging means approving the proposed changes and folding them into the main project, so they become an official part of the codebase.

What is the difference between a commit and a pull request? A commit is a single saved change. A pull request bundles one or more commits together and proposes them for review and merging. Commits are the pieces; the pull request is the proposal that packages them.

Who reviews a pull request? Usually other developers on the team, or a team lead. They read the changes, leave comments, and approve or request edits before the work is merged.