Pull Requests and Code Review
Propose changes with a pull request on GitHub, review and update it, choose a merge method, and clean up your local and remote branches afterwards.
On this page 12 sections
Introduction
On a team, nobody pushes straight to main. Instead, you push a branch and open a pull request (PR): a page on GitHub that shows your changes, lets teammates review and discuss them, runs automated checks, and merges the branch when everyone is happy. Pull requests are how most professional software — and nearly all open source — is built.
- What a pull request is and why teams use them.
- How to push a branch and open a pull request.
- How reviews work, and how to update a pull request.
- The three merge methods, and how to clean up afterwards.
What Is a Pull Request?
A pull request asks the project to “pull” the commits from your branch into another branch, usually main. It is not a Git command — it is a GitHub feature (GitLab calls the same thing a merge request). A pull request gives every change a place for:
Review
Teammates read the diff, comment on specific lines, and approve or request changes.
Discussion
Questions, decisions and screenshots stay attached to the change forever.
Automated checks
Tests and linters run automatically (with GitHub Actions) before anything is merged.
A record
Each merged PR documents what changed and why, linked to the issues it resolves.
Push a Feature Branch
Priya lists three projects on her projects page, on a new branch:
git switch -c feature/projects-list# ...edit projects.html...git commit -am "List three projects on projects page"Click Run to see what this code prints.
Then she pushes the branch to GitHub, using -u so the branch tracks its remote copy:
git push -u origin feature/projects-listClick Run to see what this code prints.
When you push a new branch, GitHub also prints a few remote: lines with a direct link for creating a pull request for it.
Open the Pull Request
- Open the repository on GitHub. A yellow banner offers “Compare & pull request” for the branch you just pushed — click it (or use the Pull requests tab → New pull request).
- Check the branches: base is the branch you want to merge into (main) and compare is your branch (feature/projects-list).
- Write a clear title, such as “List three projects on projects page”.
- In the description, explain what changed, why, and how to check it. Add screenshots for visual changes. Writing “Closes #12” automatically closes issue 12 when the PR is merged.
- Request a reviewer on the right, then click “Create pull request”. If the work is not finished, choose “Create draft pull request” instead.
Priya opens a pull request, but the Files changed tab shows dozens of commits she has never seen. The PR says: base: feature/old-redesign ← compare: feature/projects-list. What went wrong?
Reviewing a Pull Request
Reviewers open the Files changed tab, which shows the diff in the same + and - format you learned in lesson 4. They can comment on any line, suggest an exact change, and finish their review with one of three outcomes: Comment, Approve, or Request changes.
To respond to feedback, you do not open a new pull request. Make the changes on the same branch, commit and push — the pull request updates automatically with the new commits:
# ...address the review comments...git commit -am "Describe each project in one sentence"git push| Good pull request habits | Why |
|---|---|
| Keep PRs small and focused | A 50-line PR gets a careful review; a 2,000-line PR gets a skim |
| Explain the why in the description | Reviewers can check the change does what you intended |
| Review your own diff first | You will catch leftover debugging code before anyone else does |
| Be kind and specific in reviews | Comment on the code, not the person, and explain your suggestions |
Merging the Pull Request
Once approved and all checks pass, the PR can be merged with the button at the bottom of the Conversation tab. GitHub offers three methods; repository owners can choose which are allowed:
| Method | What lands on main | Good for |
|---|---|---|
| Create a merge commit | All the branch’s commits plus a merge commit | Keeping the full history of how the feature was built |
| Squash and merge | One single commit containing all the changes | A tidy main where each PR is exactly one commit |
| Rebase and merge | The branch’s commits replayed on top of main, no merge commit | A straight-line history with every individual commit |
Priya clicks “Merge pull request” with the default merge-commit method, then “Delete branch” to remove feature/projects-list from GitHub.
Cleaning Up Locally
The merge happened on GitHub, so her local main does not have it yet. She switches to main and pulls:
git switch mainClick Run to see what this code prints.
“Up to date” only means up to date with what Git last fetched — Git has not checked GitHub yet. Pulling fetches and merges:
git pullClick Run to see what this code prints.
git log --oneline --graph -3Click Run to see what this code prints.
That is the merge commit GitHub created. Now she deletes her local branch:
git branch -d feature/projects-listClick Run to see what this code prints.
Her repository still remembers the remote branch that GitHub deleted. git fetch --prune removes remote-tracking branches that no longer exist on the remote:
git fetch --pruneClick Run to see what this code prints.
git branch -aClick Run to see what this code prints.
Run git config --global fetch.prune true once, and every fetch and pull will clean up deleted remote branches for you.
Put the life of a pull request in order.
- Pull main locally and delete the branch
- Merge the pull request once approved
- Push the branch to GitHub
- Create a branch and commit your change
- Open a pull request into main
- Address review comments by pushing more commits
Pull Requests from the Terminal
The GitHub CLI (gh) can do the GitHub side without leaving the terminal. After gh auth login, these commands cover the whole flow:
| Command | What it does |
|---|---|
| gh pr create --fill | Opens a PR for the current branch, using your commit messages for the title and body |
| gh pr list | Lists open pull requests |
| gh pr checkout 7 | Downloads PR #7’s branch so you can test it locally |
| gh pr review 7 --approve | Approves PR #7 |
| gh pr merge 7 --squash --delete-branch | Squash-merges PR #7 and deletes its branch |
Common Mistakes
- Opening a new pull request for every round of feedback — push to the same branch instead.
- Choosing the wrong base branch and accidentally including someone else’s unfinished work.
- Forgetting to pull main after merging, then starting the next branch from an old main.
- Huge pull requests that mix several unrelated changes.
Frequently Asked Questions
Yes, and it is good practice: it gives you a moment to review your own diff, runs automated checks, and builds the habit you will need in a team. Recruiters also like to see clean PRs in your projects.
main changed in a way that conflicts with your branch. Merge or rebase the latest main into your branch locally, resolve the conflicts (lessons 8 and 9), and push — the PR updates.
Anyone with write access to the repository, unless the owners add rules. Teams often use branch protection to require approvals and passing checks before merging into main.
Key Takeaways
- A pull request proposes merging a branch, with review, discussion and checks on GitHub.
- Push your branch with git push -u origin <branch>, then open the PR with main as the base.
- Update a PR by pushing more commits to the same branch.
- GitHub merges with a merge commit, a squash or a rebase — choose the team’s convention.
- Afterwards: switch to main, git pull, delete the local branch, and git fetch --prune.
Summary
Priya has completed the full professional workflow: branch, push, pull request, review, merge and clean-up. Next you will use the same skills to contribute to a project you do not own — by forking it and opening a pull request to its maintainers.