Pull Requests (PRs) are at the heart of collaboration on GitHub. Whether we’re working in a team or contributing to open-source, Pull Requests help us propose changes, discuss improvements, and get feedback before anything is merged into the main project.
In this post, we’ll understand what a Pull Request is, how it works, and why it’s important—all explained in a simple and easy-to-understand way.
1. What Is a Pull Request?
A Pull Request (PR) is a request to pull changes from one branch (our branch) into another branch (usually the main branch).
In simple words: A Pull Request is how we ask someone to review and accept our changes.
It’s like saying: “Here are the changes we made. Please take a look and merge them if everything looks good.”
PRs help teams collaborate without affecting the main code until changes are reviewed.
2. When Do We Use Pull Requests?
We use PRs when:
- We create a new feature
- We fix a bug
- We improve documentation
- We update configuration or code
- We collaborate with teammates
- We contribute to open-source projects
Even when working alone, using PRs is a great habit because it creates a clean history of changes.
3. Pull Requests Always Involve Two Branches
A PR always compares:
head branch → base branch
Base branch
This is the branch we want to merge into.
Usually: main or dev.
Head branch
This is the branch that contains our changes.
Example: feature/login, fix/typo
Example:
“Merge changes from feature/payment into main.”
4. How Pull Requests Work: Step-by-Step
Here’s the entire flow in a simple sequence:
Step 1: We create a new branch
Example:
git checkout -b feature/homepage
We make changes and push them:
git push origin feature/homepage
Step 2: We create a Pull Request on GitHub
GitHub allows us to create a PR in two simple ways.
Option A — GitHub shows a banner after we push a branch
After pushing, GitHub often displays:
“Compare & pull request”
We click this to start the PR immediately.
Option B — Creating a PR from the Pull Requests tab
If we don’t see a banner or if we want to do it later:
- Open the repository on GitHub
- Click the Pull requests tab
- Click New Pull Request
- Choose:
- Base branch (target branch)
- Head branch (our branch)
Then we fill the:
- PR title
- PR description
- Optional reviewers, labels, or projects
Finally, click Create Pull Request.
GitHub now shows a confirmation page where we must:
- Select / confirm both branches (base & head)
- Enter a PR title
- Add a clear description
- Review the branch comparison (what changed)
- Optionally assign reviewers, labels, projects, milestones, assignees, etc.
Enter these details and click Create pull request again (final confirmation).
Step 3: Reviewers check our code
Reviewers check the Pull Request by going to the Files changed tab and clicking Review changes.
In the review panel, they can choose to:
- Comment → Leave feedback
- Approve → Accept the changes
- Request changes → Ask the contributor to make updates
All discussion happens inside the PR comments and the review panel.
The main Pull Request page only shows:
- Merge pull request
- Close pull request
These appear only after approvals and required checks have passed.
This is where collaboration happens.
Step 4: We make updates if needed
If reviewers ask for changes, we simply:
- Update our code in the same branch
- Push again
- The PR updates automatically
We don’t need to create a new PR unless specifically required.
Step 5: Tests and checks run (Optional)
Depending on the project, GitHub may run automated checks when we create or update a Pull Request. These checks help maintain code quality and prevent issues from reaching the main branch.
Common optional checks include:
- Automated tests
- Build and compilation checks
- Linting and formatting checks
- Security scans
- CI/CD pipeline runs
- Deployment previews
Some repositories require all checks to pass before merging.
Others may not have any checks configured at all — so this step is optional and depends entirely on the project.
Note: We will explore automated checks, CI/CD integrations, and branch protection rules in future sessions.
Step 6: The Pull Request is merged
Once approved, the main Pull Request page shows:
- Merge pull request
- Close pull request
Once approved, the PR is merged using one of the merge options:
- Merge Commit: Creates a new merge commit that joins the feature branch with the base branch. This preserves the full commit history exactly as it happened.
- Squash and Merge: Combines all commits from the feature branch into a single clean commit before merging. This keeps the main branch history simple and tidy.
- Rebase and Merge: Replays the feature branch’s commits on top of the base branch, creating a straight (linear) commit history without a merge commit.
The project owner decides which method to use.
Note: We will explore merge methods, their differences, and when to choose each one in future sessions.
Step 7: Cleanup (optional)
After merging:
- We delete the feature branch from GitHub
- We delete the branch locally
- We sync or pull the latest main branch
This keeps our repo tidy and clean.
5. Pull Request Status Labels
GitHub uses helpful labels for PRs:
- Open → PR is active and waiting for review
- Draft → Work is still in progress
- Changes Requested → Reviewer asked for updates
- Approved → Reviewer approved
- Merged → PR is successfully merged
- Closed → PR is closed without merging
These help us know exactly where things stand.
6. Why Pull Requests Are So Important
Pull Requests help us:
- Maintain code quality
- Catch issues early
- Collaborate better
- Keep the main branch stable
- Write cleaner and reviewed code
- Work like a professional development team
PRs also create a history of what changed and why.
7. Real-World Example
Let’s say we’re building a website and we want to add a new login page.
- Create branch →
feature/login - Build the login feature
- Push the branch to GitHub
- Create a Pull Request
- Team reviews the code
- Fix any comments or suggestions
- Merge the PR into
main
Now the login feature is safely added to the project.
8. Summary
Pull Requests are:
- A way to propose changes
- A place for reviews and discussions
- A safe method to merge code
- A core part of teamwork
- Essential for open-source collaboration
Once we get comfortable with PRs, we can contribute confidently to any GitHub project.