What is a pull request? (proposing changes instead of pushing them)

What it actually is

A pull request, PR for short, is a request to merge one branch of code into another, usually a feature branch into main, along with a review step before that merge actually happens. There’s no such thing as a git pull-request command; it’s a feature GitHub (and GitLab, which calls the same idea a merge request) built on top of plain git branches.

Think of it like sending a colleague a document with tracked changes turned on, instead of editing the shared master copy directly. They can see exactly what you changed line by line, leave comments on specific lines, run automated checks against it, and only then click the button that actually folds your changes into the real document. Until that click happens, the master copy is untouched.

Opening a pull request doesn’t touch your main branch at all. It just tells GitHub: “here’s a branch called fix-login-bug, I’d like it merged into main, here’s what changed and why.”

Why your AI just did this

Two different things usually trigger this. First, the repo may have branch protection turned on, a setting that flat-out rejects direct pushes to main and requires every change to arrive through a pull request instead. Second, even without that setting, a careful agent defaults to proposing changes rather than pushing them live, so you get a chance to read the diff before anything lands, especially on a shared repo, or one you didn’t start from scratch yourself.

When Claude Code opens one, it typically pushes your branch up first, then runs gh pr create with a generated title, a short summary of what changed, and often a test plan, a checklist of what to click through to confirm the change actually works. That’s there to save the reviewer (you, or a teammate) from having to reverse-engineer the diff from scratch.

When you’ll run into it

• git push gets rejected with something like “protected branch hook declined”, meaning main won’t accept a direct push, only a pull request will do
• Your agent says “I’ve opened a pull request” and hands you a github.com/…/pull/### link instead of saying the change is live
• The “Files changed” tab shows a red-and-green diff, that’s the actual review surface, read it before merging
• A “Checks” section sits pending or shows a red X, automated tests or builds still running against the branch, the merge button often won’t turn green until they pass
• A banner reads “This branch has conflicts that must be resolved”, the PR can’t merge until someone (you or the agent) fixes overlapping edits by hand

What to check

• Which branch is the PR actually merging into. Confirm the “base” is main, not some stale branch left over from earlier work
• Whether the checks are green or still pending before you click merge, a pending check isn’t a failed one, but it isn’t a pass yet either
• The “Files changed” diff actually matches what you asked for, not extra edits that snuck in alongside it
• Who needs to approve it. On your own repo it’s usually just you; on a team repo, check if a teammate’s review is required
• What happens after merge. On projects wired to Vercel or similar, merging into main can trigger an automatic production deploy, not just an update to the code

Say it like a dev

Instead of: “just put this change online” Say: “push it to a branch and open a pull request so I can see the diff before it merges”

Instead of: “why isn’t my change showing up on the site” Say: “is that pull request still open, or has it been merged into main?”

Instead of: “can you fix the merge thing” Say: “there’s a merge conflict on the PR, can you resolve it and push again”