All posts
4 min read

What Is a Pull Request? A Beginner's Guide

A pull request is how a change gets proposed, checked, and merged into a project — and it's the single best safety net when an AI agent is writing your code. What PRs are, how they work on GitHub, what to look at before you click Merge, and why you want one for every change.

getting startedtoolingAI agentsbeginner

If you connect your project to GitHub and start working with AI coding agents, you'll soon see "I've opened a pull request" or a notification about a PR. It's one of the most useful ideas in software development, and it's especially useful when the one writing the code is an AI.

The idea in one sentence

A pull request (PR) is a proposal to add a set of changes to your main project — with a place to see exactly what changed, discuss it, run checks, and then accept (merge) or reject it.

(GitLab calls the same thing a merge request. Same idea.)

Where pull requests fit

A quick recap from Git and GitHub for Beginners:

  • Your working, "official" version lives on a branch called main.
  • To make changes safely, you (or an AI) create a new branch — say, add-password-reset — and do the work there. main is untouched.

When the work is ready, you open a pull request that says: "Please pull the changes from add-password-reset into main." Nothing reaches main until someone clicks Merge.

What a pull request shows you

On GitHub, a PR has a few tabs:

  • Conversation — the description of what changed and why, plus any comments.
  • Commits — the individual save points that make up the change.
  • Files changed — the diff: every line added (green) and removed (red). This is the heart of it.
  • Checks — automatic tests or builds that ran on the change, with a green tick or red cross.

Why PRs matter so much when AI writes the code

Without pull requests, an AI agent's changes go straight into your project. With them, every change arrives as a proposal you can inspect first. That gives you:

  1. A checkpoint. You see what changed before it reaches your working app.
  2. An easy "no." If the change is wrong, close the PR. main never saw it.
  3. A record. Months later, you can see when and why something changed.
  4. Automatic checks. Tests and builds can run on every PR, catching breakage before merge. (Set Up CI With GitHub Actions.)
  5. A preview. Many hosts create a temporary live version of every PR, so you can click through the change before it goes live. (Preview Environments for Every Branch.)

What to check before clicking Merge

You don't need to understand every line. Check these:

  • Does the description match what you asked for? If it describes something slightly different, stop.
  • Is it the size you expected? A request for a small text change that touches 40 files deserves questions.
  • Are the checks green? Never merge with a red cross unless you know exactly why.
  • Did it change anything sensitive? Look at file names: database changes (migrations), login and permissions code, payment code, configuration and .env-type files, and package.json (new dependencies). (How to Review a Pull Request Written by an AI Agent goes deeper.)
  • Does it actually work? If there's a preview link, use it. Walk through the feature.

And you can always ask the AI directly: "Summarise this PR in plain English. What could go wrong with it? Did you change anything I didn't ask for?"

Merging

When you're happy, click Merge pull request. The changes join main. GitHub offers a few merge styles — the default is fine for beginners; "Squash and merge" is popular because it combines all the PR's commits into one tidy commit on main.

After merging, you can delete the branch — its work now lives in main.

If you have a host connected to GitHub, merging to main often deploys automatically. That's why the review step matters: merging may mean "this is now live."

When a PR goes wrong

  • Merge conflict: the same lines were changed on both the branch and main, and git can't decide which to keep. GitHub will say so. Ask your AI tool to "resolve the merge conflicts in this PR, keeping both changes where possible," then check the result.
  • Merged something bad: don't panic. On the merged PR, GitHub offers a Revert button, which creates a new PR that undoes it. (How to Undo Almost Anything in Git.)

Good habits

  • One PR, one purpose. Small PRs are easy to check. Huge ones get merged without being read.
  • Protect main. In GitHub's settings you can require a PR (and passing checks) for every change to main, so nothing — human or AI — can push straight to it.
  • Read before merging. Even a 30-second skim of the file list catches surprises.

EasySpawn connects to GitHub so Claude Code can work on a branch and open a pull request for you to review — with a live URL per branch on Pro so you can click through the change before merging. See how it works or join the waitlist.

Related: Git and GitHub for Beginners · How to Review a Pull Request Written by an AI Agent · Git Branches Explained · How to Read a Diff

Keep reading