Pull Request Basics

Pull requests (PRs) are how you propose changes on GitHub. They're the center of collaborative development, enabling code review, discussion, and automated testing before changes are merged.

What is a Pull Request?

A pull request says: "I have changes in my branch that I'd like to merge into your branch."

Your Branch (feature)     →     Target Branch (main)
       ↓                              ↓
   Your commits           Request to merge
   awaiting review            into main

Despite the name "pull" request, you're actually asking the maintainer to pull your changes into their branch.

Creating a Pull Request

From GitHub Web UI

1. Push your branch to GitHub
2. Go to the repository
3. Click "Compare & pull request" (appears after pushing)
4. Or: Pull requests tab → New pull request

From Command Line (GitHub CLI)

# Create PR interactively
gh pr create

# Create PR with title and body
gh pr create --title "Add login feature" --body "Description here"

# Create and open in browser
gh pr create --web

Pull Request Components

Title

Short, descriptive summary:

• ✅ "Add user authentication with JWT"
• ✅ "Fix memory leak in image processor"
• ❌ "Changes"
• ❌ "Fix bug"

Description

Explain what and why:

## Summary
Brief description of what this PR does.

## Changes
- Added login endpoint
- Created User model
- Added authentication middleware

## Testing
How to test these changes:
1. Run `npm test`
2. Try logging in with test credentials

## Related Issues
Closes #123

Labels

Categorize your PR:

• bug, feature, enhancement
• documentation, refactor
• breaking-change, needs-review

Reviewers

Request specific people to review your code.

Assignees

Who's responsible for the PR.

Linked Issues

Connect to related issues:

• "Closes #123" (auto-closes when merged)
• "Fixes #456"
• "Relates to #789"

The PR Lifecycle

1. Create Branch
       ↓
2. Make Commits
       ↓
3. Push to GitHub
       ↓
4. Create PR ←────────────────┐
       ↓                      │
5. CI Checks Run              │
       ↓                      │
6. Code Review ─── Requested Changes
       ↓
7. Approval
       ↓
8. Merge
       ↓
9. Delete Branch

PR Status Checks

GitHub can run automated checks:

Check	Purpose
CI Tests	Run automated tests
Linting	Check code style
Build	Verify it builds
Security	Scan for vulnerabilities
Coverage	Check test coverage

PRs can require checks to pass before merging.

Viewing a Pull Request

Files Changed Tab

Shows the diff:

• Green: Added lines
• Red: Removed lines
• Yellow: Modified files

Conversation Tab

• Description
• Comments and discussion
• Review summaries
• Check statuses

Commits Tab

List of all commits in the PR.

Checks Tab

Status of automated checks.

Updating a Pull Request

Adding More Commits

Simply push more commits to the same branch:

# Make changes
git add .
git commit -m "Address review feedback"
git push

The PR automatically updates.

Keeping Up with Base Branch

If the target branch has new commits:

# Merge approach
git fetch origin
git checkout feature
git merge origin/main
git push

# Rebase approach (cleaner history)
git fetch origin
git checkout feature
git rebase origin/main
git push --force-with-lease

Merge Options

When merging a PR, you have options:

Merge Commit

main:    ─────────────M
                     /
feature: ───────────

Preserves full history with merge commit.

Squash and Merge

main:    ─────────────S (single commit)

Combines all PR commits into one.

Rebase and Merge

main:    ─────────────A'─B'─C' (rebased commits)

Applies commits linearly without merge commit.

Closing Pull Requests

Merging

Click "Merge pull request" when approved and checks pass.

Closing Without Merging

For PRs that won't be merged:

• Click "Close pull request"
• Leave a comment explaining why

Draft → Ready

For draft PRs, click "Ready for review" when done.

Best Practices

Keep PRs Small

• Easier to review
• Faster to merge
• Lower risk

Aim for < 400 lines changed.

One Thing Per PR

Each PR should do one logical thing:

• One feature
• One bug fix
• One refactor

Write Good Descriptions

Help reviewers understand:

• What changes were made
• Why they were made
• How to test

Respond to Feedback

• Address all comments
• Explain your decisions
• Be open to suggestions

Summary

• PRs are proposals to merge changes
• Include clear title, description, and context
• Link related issues
• Automated checks run on PRs
• Keep PRs small and focused
• Respond to review feedback
• Choose appropriate merge strategy

In the next lesson, we'll learn about code review best practices.