What Is a Pull Request? A Plain-English Guide

A pull request is a proposal to merge a set of code changes into a project. Someone finishes work on a separate branch, opens a pull request, and the team reads the changes, discusses them, and runs automated checks before anything joins the main code. GitHub describes pull requests as "proposals to merge code changes into a project", and that is the whole idea in one line.

The name is a little backwards. You are not pulling anything. You are asking the owner of the main branch to pull your changes in, so "merge request" is arguably the better label, and GitLab uses it.

Why a pull request exists

Without one, a change goes straight from one person's machine into the shared code. A pull request puts a pause in the middle. The pause gives you three things:

• A diff, which is the exact list of lines added and removed.

• A conversation attached to those lines, so questions stay next to the code they are about.

• A gate, because checks like tests and builds can run on the proposed change before it lands.

If you build with an AI coding tool, this matters more, not less. An agent can produce a large change in minutes. The pull request is where a human decides whether that change belongs in the project.

The four tabs, in the order to read them

GitHub's documentation lists the sections of a pull request page. They are worth reading in this order, because each one answers a different question.

1. Conversation. The description, the timeline, comments, and reviews. Read the description first. It should say what changed and why in two or three sentences. If it only says "updates", that is already a finding.

2. Checks. Automated tests, builds, and other validations. A red check is a fact, not an opinion, so look here before you spend time on style.

3. Commits. How the branch changed over time. Useful for spotting a change that mixes unrelated work.

4. Files changed. The diff itself. This is where reviewers do most of their reading.

Most people jump straight to the diff. Reading the description and the checks first costs two minutes and often tells you whether the diff is worth the effort yet.

Draft pull requests

A draft pull request is a pull request that is not ready to merge. GitHub says a draft "cannot be merged", and that code owners are not automatically asked to review it. You open one to show work in progress or to get early feedback, then mark it ready for review when you are done. You can also convert a pull request back to a draft at any time.

What happens when it merges

When the pull request is approved and the checks pass, someone merges it. The merge box shows blockers, missing approvals, and other requirements before you can do that. Teams usually choose between a merge commit, a squash, or a rebase, and the choice changes how history looks afterwards. The branch itself is usually deleted once its work is in. If the word branch is fuzzy, the explainer on what a git branch is covers it in a few minutes.

Reading a pull request an AI agent wrote

An agent's pull request looks exactly like a human's. The risk is different. Humans tend to under-explain a diff. Agents tend to produce a large, confident diff with a tidy description, and the tidy description can hide what actually changed.

A short routine helps:

1. Compare the description to the file list. If the description mentions two files and the diff touches fourteen, ask about the other twelve.

2. Look for files nobody asked about. Config files, lockfiles, CI workflows, and environment examples deserve a second look. The post on reviewing an AI agent's git diff before merging goes through this in detail.

3. Check the tests changed for the right reason. A test that was edited to pass is worse than a test that fails.

4. Ask for smaller pull requests. A change you can read in ten minutes gets read. A change that takes an hour gets skimmed. There is a full guide to getting an AI coding agent to write smaller pull requests.

5. Use an AI reviewer as a second reader, not the only one. It is good at catching a missed null check and bad at knowing what your business needs. The same idea applies when you let an agent do the first review pass.

A pull request description worth writing

If you are the one opening it, a good description has three parts:

• What changed, in plain words.

• Why it changed, with a link to the issue or the request.

• How you checked it works, such as the command you ran or the screen you clicked through.

If you want a draft to start from, the guide to writing a pull request description with AI shows a prompt that works.

Where pull requests fit in the bigger picture

A pull request is one step in a longer workflow: branch, change, propose, review, merge. The overview of AI coding tools shows where agents slot into that workflow and where a person still needs to be.

FAQ

What is a pull request in simple terms?

It is a request to add your changes to a shared project. The team can read the changes, comment, and run checks before the change is merged.

What is the difference between a pull request and a merge?

A pull request is the proposal and the review. A merge is the final step that actually combines the code. You can have a pull request that never gets merged.

Is a pull request the same as a merge request?

Yes, in practice. GitHub says pull request and GitLab says merge request, but both describe a reviewed proposal to combine code.

Do I need a pull request if I work alone?

You do not need one, but many solo builders use them anyway. The checks run, the diff is easy to read, and the history shows what changed and why.

Who approves a pull request?

Whoever your project designates. Small teams often rely on one teammate. Larger projects can require specific code owners or a set number of approvals before the merge button works.