Lesson 10: Pull Requests

What You'll Learn

In this lesson, you'll learn about Pull Requests (PRs) - GitHub's way of proposing, reviewing, and merging code changes. This is how professional teams collaborate on projects.

What is a Pull Request?

A Pull Request is a request to merge your branch into another branch (usually main). It's called a "pull request" because you're asking the maintainer to "pull" your changes.

Real-world analogy:

Think of it like submitting an article to a magazine:

  • You write your article (your feature branch)
  • You submit it for review (create a pull request)
  • Editors review and suggest changes (code review)
  • You make revisions (push more commits)
  • Article gets published (PR is merged)

Why Use Pull Requests?

  • Code Review: Others can review your code before it's merged
  • Discussion: Team can discuss changes and suggest improvements
  • Quality Control: Catch bugs before they reach main
  • Documentation: Creates a record of what changed and why
  • Collaboration: Multiple people can contribute to the same PR

Part 1: Creating a Pull Request

Step 1: Create and Push a Feature Branch

# Create feature branch
git switch -c feature/add-about-page

# Make changes
echo "<h1>About Us</h1>" > about.html
git add about.html
git commit -m "Add about page"

# Push to GitHub
git push -u origin feature/add-about-page

Step 2: Create PR on GitHub

  1. Go to your repository on GitHub
  2. You'll see a yellow banner: "feature/add-about-page had recent pushes"
  3. Click "Compare & pull request"
  4. Or go to the Pull requests tab and click "New pull request"

Step 3: Fill in PR Details

Field What to Include
Title Clear summary: "Add about page with company info"
Description What changed, why, and how to test it
Reviewers Select team members to review
Assignees Who's responsible for this PR
Labels bug, feature, documentation, etc.

Step 4: Create the Pull Request

Click "Create pull request". Your PR is now open for review!

Part 2: Writing Good PR Descriptions

Good PR Description Template

## What Changed
- Added new about page
- Created about.html with company information
- Linked about page from main navigation

## Why
Users requested more information about our company.

## How to Test
1. Run the project locally
2. Navigate to /about.html
3. Verify company info displays correctly

## Screenshots
[Include screenshots if relevant]

## Related Issues
Fixes #123

Tips for Great PRs

  • Keep it small: Smaller PRs are easier to review
  • One feature per PR: Don't mix unrelated changes
  • Clear title: Summarize the change in one line
  • Explain why: Context helps reviewers understand
  • Add screenshots: Visual changes benefit from images

Part 3: Reviewing a Pull Request

As a Reviewer

  1. Open the Pull Request
  2. Read the description
  3. Click the Files changed tab
  4. Review the code:
    • Look for bugs
    • Check code quality
    • Verify it follows project standards
    • Test the changes if possible
  5. Leave comments by clicking the + icon next to lines
  6. Submit your review:
    • Approve: Looks good!
    • Request changes: Needs fixes
    • Comment: Just providing feedback

Types of Comments

Comment Type Example
Suggestion "Consider using const instead of let here"
Question "Why did you choose this approach?"
Nitpick "Nit: Missing semicolon (not blocking)"
Praise "Nice refactoring! Much cleaner now."
Blocker "This will break feature X. Must fix before merge."

Part 4: Responding to Review Comments

Make Requested Changes

# Still on your feature branch
# Make the requested changes

git add .
git commit -m "Address review comments"
git push

The PR automatically updates with your new commits!

Replying to Comments

  • Ask for clarification: "Can you explain what you mean?"
  • Acknowledge: "Good catch! Fixed in latest commit."
  • Discuss: "I chose this approach because..."
  • Mark resolved: Click "Resolve conversation" when fixed

Part 5: Merging a Pull Request

When Ready to Merge

  1. All reviewers have approved
  2. All comments are resolved
  3. Tests pass (if you have automated tests)
  4. No merge conflicts

Merge Methods

Method Result When to Use
Merge commit Creates a merge commit Default, keeps full history
Squash and merge Combines all commits into one Clean history, for small features
Rebase and merge Adds commits linearly Clean linear history

Click the Merge Button

  1. Click "Merge pull request"
  2. Confirm the merge
  3. Optionally delete the branch

Part 6: After Merging

Update Your Local Repository

# Switch to main
git switch main

# Pull the merged changes
git pull

# Delete the local feature branch
git branch -d feature/add-about-page

The PR is Now Closed

The PR moves to "Closed" state and shows it was merged. All comments and discussion are preserved for future reference.

Part 7: Draft Pull Requests

Use draft PRs when work is not ready for review:

  • Create PR as "Draft"
  • Share work-in-progress with team
  • Get early feedback
  • Mark as "Ready for review" when done

Practice Exercise

  1. Create a new branch in your practice repository
  2. Make a simple change (add or edit a file)
  3. Commit and push the branch
  4. Go to GitHub and create a Pull Request
  5. Write a descriptive title and description
  6. If working with others, request a review
  7. Merge the Pull Request
  8. Pull the changes locally and delete the branch

Summary

Pull Request Workflow

Step Action
1. Create branch git switch -c feature/name
2. Make changes Edit files, commit
3. Push branch git push -u origin feature/name
4. Create PR On GitHub, click "Compare & pull request"
5. Review & discuss Team reviews code, suggests changes
6. Merge Click "Merge pull request"
7. Clean up Delete branch, pull main locally

Key benefit: Pull Requests enable code review and team collaboration!

What's Next?

In the next lesson, you'll learn advanced ways to view your project's history - using git log, git diff, and other tools to explore what changed over time.