What is a Pull Request? | Glossary

A pull request, or PR, is a request to add a set of code changes to the main version of a project. Instead of editing the live code directly, a developer works on a separate branch, then opens a pull request so others can see exactly what changed, comment on it and approve it before it is merged.

How a pull request moves from branch to merge

1. The developer creates a branch, for example fix-booking-dates, and makes one or more commits on it.
2. They push the branch to the shared repository and open a pull request asking to merge it into main.
3. The PR page shows a diff: every added line in green, every removed line in red. Reviewers leave comments on specific lines or request changes.
4. Automated checks run, such as tests and a preview build. Many teams block merging until these pass.
5. Once approved, someone clicks merge and the branch's commits join the main line.

The name comes from asking the project owner to pull your changes in. GitHub and Bitbucket call it a pull request; GitLab calls the same thing a merge request. Plain Git has no pull request feature of its own; it is something hosting services add.

Example: reviewing a change before customers see it

A dental practice's developer opens a PR titled "Add Saturday appointments to booking form". Vercel, connected to the repository, posts a link in the PR to a preview copy of the site built from that branch. The office manager clicks it, tries a Saturday booking, and spots that the confirmation email still says "Monday to Friday". The developer adds a commit fixing the text, the preview updates, and only then is it merged and released.

Is this relevant to a small business?

Only if a developer or team is changing your site's code. In that case, asking for changes to arrive as pull requests, ideally with a preview link, is one of the cheapest ways to stop surprises reaching customers. A solo developer working alone often skips PRs; that is fine for tiny edits but risky for anything touching payments or forms.

Where pull requests go wrong

• Huge PRs. A pull request with thousands of changed lines gets skimmed and approved without real review. Split work into smaller pieces.
• No description. Explain what changed, why and how to test it. Screenshots help non-developers.
• Merging with failing checks. Red checks exist to catch breakage before release.
• Letting branches go stale. A PR left open for weeks falls behind main and collects conflicts.

Related terms

• GitHub: where most pull requests are opened.
• Commit: the units a pull request bundles together.
• CI/CD: the automated checks that run on each PR.
• Staging environment: another place to test changes before release.