GitHub Pull Requests & Code Review

Reviewed & published by Brayan K

Pull requests are how real teams ship code together. By the end of this lesson you'll push a branch, open a PR, review someone else's changes with approvals and inline comments, and merge it cleanly — the everyday loop of collaborative software.

Part of the free Git course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

What You'll Learn

• Push a feature branch and open a pull request against a base branch
• Write a clear PR title/description and auto-close issues with 'Closes #'
• Use draft PRs to share work-in-progress safely
• Review with inline comments and the Approve / Comment / Request changes verdicts
• Pick a merge strategy: merge commit, squash, or rebase
• Clean up: delete the merged branch and update your local main

1️⃣ Push the Branch

A PR can only exist for a branch GitHub can see, so the first step is always to push. Use git push -u origin <branch> — the -u sets the upstream so future pushes are just git push, and GitHub immediately prints a link to open the PR.

# A pull request starts with a branch GitHub can see. So: branch, commit,
# and PUSH the branch up to the remote first.

# 1) Make your change on a feature branch
git switch -c add-login

echo "login form" > login.js
git add login.js
git commit -m "Add login form"

# 2) Push the branch and set its upstream so future pushes are just 'git push'
git push -u origin add-login

# Git prints a handy link to open the PR straight from the terminal output.

2️⃣ Open the Pull Request

In GitHub, click Compare & pull request, set the base (the branch you merge into, usually main) and the compare branch (your changes), then write a clear title and description. Add Closes #42 to auto-close an issue on merge, or open a draft if it's still in progress.

# Opening the PR (in the GitHub web UI):
#
# 1. Click "Compare & pull request" (GitHub shows it after a push)
# 2. Choose the BASE branch (merge INTO, usually main) and the COMPARE
#    branch (your changes, e.g. add-login)
# 3. Write a clear title and a description of WHAT and WHY
# 4. Link issues so they auto-close on merge:
#       Closes #42
# 5. Open as a normal PR, or click the dropdown to "Create draft pull
#    request" if it's still work-in-progress
#
# Prefer the command line? The GitHub CLI does the same:
gh pr create --base main --head add-login --title "Add login form" --fill

# Mark a finished draft ready for review:
gh pr ready

3️⃣ Review the Changes

Reviewing happens on the Files changed tab. Leave inline comments on specific lines, then submit a single review with one verdict: Comment (feedback only), Approve (good to merge), or Request changes (blocks the merge until addressed).

# REVIEWING someone's PR (web UI):
#
# 1. Open the PR and click the "Files changed" tab to read the diff
# 2. Hover a line and click the + to leave an inline comment
# 3. Click "Review changes" (top-right) and choose ONE verdict:
#       • Comment        — feedback, no explicit approval
#       • Approve         — looks good, safe to merge
#       • Request changes — blocks the merge until addressed
# 4. Submit the review; the author gets notified
#
# From the CLI you can do the same:
gh pr review 57 --approve
gh pr review 57 --request-changes --body "Please add a test"

Your turn. Get a feature branch onto GitHub so it's ready for a PR. Fill in the one blank.

# 🎯 YOUR TURN — replace each ___ then run it in a repo with a GitHub remote.
# Goal: get a feature branch onto GitHub and ready for a PR.

# 1) Create a feature branch
git switch -c fix-typo

# 2) Make + commit a small change
echo "fixed" > notes.txt
git add notes.txt
git commit -m "Fix typo in notes"

# 3) Push the branch AND set its upstream in one go
git push ___ origin fix-typo    # 👉 the flag that sets the upstream

# ✅ Expected: Git prints a "Create a pull request" link for fix-typo.
#    Open it, set the base to main, add a title, and submit.

4️⃣ Merge and Clean Up

Once it's approved and checks pass, merge with the strategy your team prefers: a merge commit (keeps all commits), squash and merge (one tidy commit), or rebase and merge (linear, no merge commit). Then delete the merged branch and pull main locally.

# MERGING the PR once it's approved and checks pass. GitHub offers three
# strategies — pick one that fits your team's history style:
#
#   • Create a merge commit  — keeps every commit + a merge commit
#   • Squash and merge       — combines all commits into ONE tidy commit
#   • Rebase and merge       — replays commits onto base, linear, no merge commit
#
# After merging, delete the now-redundant branch (GitHub offers a button),
# then update your local copy:
git switch main
git pull
git branch -d add-login        # the merged branch is safe to remove

# CLI equivalent:
gh pr merge 57 --squash --delete-branch

Common Errors (and the fix)

• "No 'Compare & pull request' button": you didn't push the branch, or pushed to the wrong remote. Run git push -u origin <branch> and refresh.
• PR shows far more changes than expected: your branch is behind main. Update it (merge or rebase main in) so the diff only shows your work.
• Can't merge — "Changes requested": a reviewer used Request changes. Address the comments, push the fixes, and ask for a re-review.
• Merge button greyed out: required status checks (CI) haven't passed, or required reviews are missing. Fix the checks and get the approvals.
• Issue didn't auto-close: the closing keyword must be in the PR description/commit and the issue in the same repo — use Closes #N, not just "#N".

Pro Tips

• 💡 Small PRs get reviewed faster: one focused change per PR beats a giant one.
• 💡 Describe the "why": reviewers approve faster when the description explains the reasoning, not just the code.
• 💡 Use draft early: open a draft as soon as CI matters, so checks run while you keep working.
• 💡 Learn gh: gh pr create, gh pr checkout 57, and gh pr merge keep you in the terminal.

📋 Quick Reference

Mini-Challenge: A Full PR Round-Trip

No commands given this time — just the plan. Take a change from branch to merged PR, draft and review included.

# 🎯 MINI-CHALLENGE: a full PR round-trip.
# No commands given — just the plan. Use a practice repo on GitHub.
#
# 1. Branch, make a change, and push it with -u to set the upstream
# 2. Open a pull request, base = main, with a clear title + "Closes #1"
# 3. Open it first as a DRAFT, then mark it ready for review
# 4. On the "Files changed" tab, leave at least one inline comment
# 5. Approve it, then "Squash and merge" and delete the branch
#
# ✅ Expected: the issue auto-closes on merge, history shows one squashed
#    commit on main, and the feature branch is gone.

# your commands here

🎉 Lesson Complete!

• ✅ Push a branch with -u before opening a PR
• ✅ A PR merges a compare branch into a base branch, with review built in
• ✅ Draft PRs share work-in-progress without allowing a merge
• ✅ Reviews are Approve, Comment, or the blocking Request changes
• ✅ Merge with a merge commit, squash, or rebase — then delete the branch

Practice quiz

Continue this course

• Previous: Git Configuration & Aliases
• Next: Forking & Contributing to Open Source — Fork a project, keep it in sync with upstream, and contribute via PRs
• Quick reference: Git cheat sheet

Frequently asked questions

What exactly is a pull request?

A pull request is a proposal to merge the commits on one branch (the compare/head branch) into another (the base branch, often main). It's not a Git command — it's a GitHub feature that wraps your branch in a page where teammates can read the diff, run automated checks, discuss line by line, and approve or request changes before anything lands on the base branch.

Why do I have to push my branch before opening a PR?

GitHub can only build a pull request from a branch it can actually see on the remote. Your local commits live only on your machine until you push, so the first step is always git push -u origin <branch>. The -u sets the upstream so later pushes are just git push, and GitHub immediately offers a 'Compare & pull request' button.

What's the difference between Approve, Comment, and Request changes?

These are the three review verdicts. 'Comment' leaves feedback without a formal decision. 'Approve' says you're satisfied and, under required-review rules, lets the PR merge. 'Request changes' is a blocking verdict — it signals problems that must be fixed, and typically prevents merging until the author addresses them and the reviewer re-reviews.

Should I use a merge commit, squash, or rebase merge?

Create a merge commit keeps every individual commit plus a merge commit, preserving full history. Squash and merge collapses the whole branch into one clean commit on the base — great for tidy history and small features. Rebase and merge replays your commits onto the base for a linear history with no merge commit. Teams usually standardize on one; squash is a popular default.

What is a draft pull request?

A draft PR is a work-in-progress signal. You can open it early to share direction, run CI, and gather feedback, but GitHub blocks the merge button and (by default) doesn't request reviews until you click 'Ready for review'. It's the polite way to say 'this isn't done yet — look, but don't merge'.

Related lessons

• Working with Remote Repositories