What Is a PR? The Pull Request Workflow from Open to Merge

Updated

A PR (Pull Request) is a request to merge changes from one branch into another, and it exists so those changes can be reviewed, discussed, and tested before they land. You need one whenever you want a change to reach a shared branch such as main without pushing to it directly. The workflow below covers what happens between opening a PR and merging it, plus the points where PRs usually stall.

What a PR actually is

A PR is not a Git command. Git itself only knows about branches, commits, and merges. The pull request is a feature of the hosting platform (GitHub, GitLab, Bitbucket, and similar), which wraps a proposed merge in a reviewable page.

That page is where the value sits. It collects, in one place:

  • The diff — every line added, removed, or changed, per file
  • The commit history — the individual commits that make up the branch
  • Review status — who approved, who requested changes, who hasn't looked yet
  • Comment threads — line-level and general discussion
  • CI check results — build, lint, and test outcomes for that branch

The name "pull request" comes from the maintainer's side: you're asking them to pull your changes into their branch. GitHub's own UI shows the same information — line changes, review state, and checks — which is why tools that summarize PRs often lead with the diff size and review status.

The PR workflow, step by step

1. Branch off the target

Create a branch from the branch you intend to merge into, then commit your work there. Keeping the branch short-lived and focused is what makes the rest of the steps fast.

2. Open the PR

Push the branch and open a PR against the target branch. At this point you write the description: what changed, why, and anything a reviewer needs to know to evaluate it. The PR now exists in an open state and is visible to everyone with access.

3. Review and comment

Reviewers read the diff and either approve, request changes, or leave comments. Comments can be attached to specific lines, which keeps the discussion anchored to the code instead of a chat thread. This stage is where code review happens — the PR is the container, review is the activity inside it.

4. Revise and update

You push more commits to the same branch. The PR updates automatically; you don't open a new one. Review threads get resolved as they're addressed.

5. Wait for CI

Automated checks run against the branch. If a check fails, the PR isn't ready to merge regardless of approvals. A failing check on the target branch itself is a separate signal — for example, GitNotifier's sample notifications include an alert that "your default branch workflow lint failed," which tells the team the merge broke main's CI rather than just the PR.

6. Merge

Once approvals and checks are satisfied, the PR is merged into the target branch. Many platforms offer one-click merge from the PR page, and some tools extend that to merging from a chat client when all checks pass.

Why small PRs move faster

Review effort scales with diff size, not with how important the change is. A 30-line PR gets read carefully in a few minutes; a 900-line PR gets skimmed, and skimming is where bugs survive review. The practical rule most teams land on: one logical change per PR, split refactors from behavior changes, and keep the branch rebased so the diff shows only your work.

Where PRs get stuck

Symptom Usual cause What unblocks it
PR sits open for days Reviewers never saw the request Direct notification to the reviewer, or a scheduled digest of PRs awaiting your review
CI red Failing test, lint, or build step Fix on the branch; the PR re-runs automatically
Merge conflict Target branch moved ahead Rebase or merge the target branch into yours, resolve, push
Approvals but no merge Nobody owns the final click Assign a merger, or merge directly once checks pass
Review noise Everything routed to one shared channel Route only the notifications that matter to each person

The first and last rows are the same problem from two directions: the PR is ready, but the right person doesn't know it. That's the gap notification tooling targets. GitNotifier, for instance, sends PR notifications to Slack DMs rather than a shared channel — review requests, comments, approvals, and CI failures — and lets you reply to comments, react with emoji, and merge from Slack when checks pass. It also offers a scheduled digest of PRs waiting on your review. Whether that's worth adopting depends on whether your team's bottleneck is review latency or something else; if PRs are slow because they're too large, notifications won't fix it.

FAQ

Is a PR the same as a merge? No. A PR is a proposal; merging is the action that applies it. A PR can be closed without ever being merged.

Do I need a PR to merge branches? Technically no — you can merge locally and push. Teams require PRs because the review and CI record is the point.

What's the difference between a PR and a code review? The PR is the artifact (diff, commits, checks). Code review is the process of people examining it. Every PR review happens on a PR; not every PR gets reviewed.

Can I merge without approval? That's a branch protection setting, not a PR rule. Many teams require at least one approval plus passing checks before the merge button activates.