Once you're comfortable with Git, the next term you'll run into constantly is Pull Request, or PR. On almost every engineering team that uses GitHub, code doesn't go straight into the main branch — it goes in through a Pull Request.

This article explains what a Pull Request is, how the flow works, and habits for opening PRs that are easy to review.

What is a Pull Request?

A Pull Request is a request to merge changes from one branch into another — usually from a feature branch into main. But a PR is more than a merge button. A PR is a discussion space where code changes are:

shown line by line (the diff),
explained by the author,
checked automatically (tests, lint, build),
reviewed and commented on by teammates,
improved until ready, then merged.

On GitLab, the same concept is called a Merge Request.

The word "pull" comes from the repository owner's perspective: you're asking them to pull your changes into their branch.

Why do teams use Pull Requests?

Quality. Every change is seen by at least one other person before it lands.
Knowledge sharing. Reviewers learn which parts of the code changed, and authors learn from the feedback.
A record of decisions. Discussions in the PR explain why a change was made — useful months later.
Automation. PRs trigger CI that runs tests and other checks.

The Pull Request flow from start to merge

Here's the common flow. If the Git commands below aren't familiar yet, read Git for Beginners first.

1. Create a branch from the latest `main`

git switch main
git pull
git switch -c feature/order-filter

2. Make changes and commit in small steps

git add .
git commit -m "Add status filter to the order list"

3. Push the branch to GitHub

git push -u origin feature/order-filter

4. Open a Pull Request

On GitHub, open the repository and choose Compare & pull request. Make sure the direction is right: base main, compare your feature branch. Fill in the title and description.

5. Wait for automated checks

If the repository has CI, tests and other checks will run. Fix any failures first — reviewers usually won't review a PR with red CI.

6. Review and discussion

Reviewers leave comments: questions, suggestions, or requested changes. On GitHub, the review status is usually Comment, Approve, or Request changes.

7. Fix and push again

You don't need to open a new PR. Just commit the fixes on the same branch and push — the PR updates automatically.

8. Merge

Once approved and all checks pass, the PR is merged into main. The feature branch is usually deleted afterwards.

Anatomy of a good Pull Request

A title that describes the outcome

A PR title should describe what changed in terms of the outcome, not the process.

Unclear: Update order page
Clearer: Add status filter to the order list page

A description that answers three questions

What changed?
Why is this change needed? (link to the ticket/PRD if there is one)
How can it be tested or verified?

A short example description:

## What
Adds a status filter (pending, paid, shipped) to the order list page.

## Why
The operations team needs to see unshipped orders without scrolling the whole list.

## How to test
1. Open /orders
2. Select the "paid" status — only paid orders are shown
3. Clear the filter — all orders are shown again

A reasonable size

A PR that's too big is hard to review carefully. Reviewers tend to miss details when facing hundreds of changed lines at once. If the feature is large, split it into several PRs that can each stand on their own.

Focused on one purpose

Don't mix bug fixes, refactoring, and new features in one PR. If you find something else that needs fixing, open a separate PR.

Review it yourself first

Before asking for review, open the Files changed tab and read your changes as if you were the reviewer. You'll often find leftover console.log calls, commented-out code, or unclear variable names.

Common mistakes when opening a Pull Request

Empty description. Reviewers are forced to guess the context.
Opening a PR for unfinished work without saying so. Use a Draft Pull Request if you want to share progress.
Ignoring failing CI. Fix it before asking for review.
Being defensive about comments. Review comments assess the code, not you. How to respond is covered in Code Review for Beginners.
Careless force pushes after review has started. This can wipe out comment context. Follow your team's conventions.

How to practice Pull Requests

Pull Requests are easiest to learn by doing them over and over:

Get into the habit of opening a PR to your own repository for each feature, then reviewing before merging.
Contribute to open source projects that welcome new contributors.
Join a program that makes Pull Requests and review a core part of practice.

Conclusion

A Pull Request is how engineering teams bring code changes in safely: changes are explained, checked automatically, reviewed, improved, then merged. A good PR has a clear title, a description that answers what–why–how, a reasonable size, and a single focus.

In the KodingCamp software engineer job simulation, every mission is submitted through a Pull Request and reviewed by an AI Tech Lead — so you practice this flow in conditions close to real work. See the full workflow in The Software Engineer Workflow.

What Is a Pull Request? How It Works and How to Write a Good One