What Is a Pull Request?

A pull request (PR) is a proposal to merge changes from one branch into another. The name comes from the original action: you are asking the repository maintainer to “pull” your changes in. On GitHub, pull requests are a structured process — not just a merge, but a conversation about the merge.

The problem pull requests solve

Without pull requests, everyone pushes directly to main. This works for solo projects, but on a team it creates problems:

• Changes land without review — bugs and design mistakes go unnoticed
• Two developers might conflict without realizing it
• There is no record of why a change was made or what alternatives were considered
• There is no checkpoint before code reaches production

Pull requests create a review step. Changes go into a feature branch, a PR opens against main, teammates review the code and leave comments, and the author addresses feedback before merging. The PR itself becomes a documented record of the change.

The pull request workflow

1. Create a feature branch — do your work on a branch, not on main
2. Push the branch to GitHub — git push -u origin feature/your-branch
3. Open a pull request on GitHub — propose merging your branch into main
4. Review happens — teammates (or just you, reviewing your own work) look at the diff, leave comments, request changes
5. Address feedback — push additional commits to the same branch; the PR updates automatically
6. Merge — once approved, the branch is merged into main
7. Delete the branch — cleanup after merge

Pull requests are a GitHub feature, not a Git feature

git has no concept of a pull request. When you run git push, Git just sends commits — it has no idea what happens next. Pull requests are a layer GitHub (and GitLab, Bitbucket, and Azure DevOps) add on top of Git branches.

This means everything you learned about branches in Module 03 is exactly what powers pull requests. A PR is just a feature branch + a GitHub UI for reviewing and merging it.

Solo developers and pull requests

Even working alone, pull requests are worth using:

• Self-review: opening a PR and reading the diff catches things you miss when you are writing the code
• Documentation: the PR description becomes a record of why you made the change
• Portfolio: public GitHub repositories with PRs look more professional than repositories with only direct commits to main
• Practice: the habit is essential when you join a team — build it now

The STO project in Module 07 will use pull requests for this reason.

What you will learn in this module

• Creating a branch, pushing it, and opening a PR
• Reading a pull request — the diff view, the files changed tab, inline comments
• Merging strategies on GitHub (merge commit, squash, rebase)
• Handling a PR that has merge conflicts
• Pull request etiquette: good descriptions, small focused changes, responding to review

Recap

• A pull request is a proposal to merge one branch into another, reviewed and discussed on GitHub before merging.
• Pull requests solve the “push directly to main” problem by creating a review and documentation step.
• PRs are a GitHub feature, not a Git feature — they work on top of branches you already know how to use.
• Solo developers benefit from PRs too: self-review, documentation, and portfolio value.

The next lesson walks through creating your first pull request — from branch to merge.