Git & GitHub

Pull Requests

13 min Lesson 21 of 35

Pull Requests

Pull Requests (PRs) are one of GitHub's most powerful collaboration features. They provide a structured way to propose changes, facilitate code review, and merge code safely into your main codebase.

What are Pull Requests?

A Pull Request is a request to merge code from one branch into another. It's called a "pull request" because you're asking the repository maintainer to "pull" your changes into their branch.

Key Concept: Pull Requests are not a Git feature - they're a GitHub feature that enhances Git workflows. Other platforms like GitLab call them "Merge Requests."

The Pull Request Workflow

Here's the typical PR workflow:

Create a feature branch from main
Make changes and commit them
Push the branch to GitHub
Open a Pull Request
Code review and discussion
Make requested changes (if any)
Approval from reviewers
Merge the PR into main branch
Delete the feature branch

Creating Your First Pull Request

Let's create a PR step by step:

# Step 1: Create and switch to a new branch
git checkout -b feature/add-contact-page

# Step 2: Make your changes
echo "<h1>Contact Us</h1>" > contact.html
git add contact.html
git commit -m "Add contact page"

# Step 3: Push the branch to GitHub
git push -u origin feature/add-contact-page

After pushing, GitHub will display a link to create a Pull Request. You can also create one manually:

Go to your repository on GitHub
Click "Pull requests" tab
Click "New pull request"
Select your feature branch as the "compare" branch
Select main as the "base" branch
Click "Create pull request"

Writing Effective PR Descriptions

A good PR description should explain WHAT changed and WHY:

Title: Add contact page for customer inquiries

Description:
## What
- Created new contact.html page
- Added contact form with email validation
- Integrated with SendGrid API for email delivery

## Why
- Users requested a way to contact support
- Reduces support email volume by 30%
- Closes #42

## Testing
- [x] Form validation works correctly
- [x] Email delivery tested on staging
- [x] Mobile responsive design verified

## Screenshots
[Attach relevant screenshots]

Pro Tip: Use keywords like "Closes #42" or "Fixes #42" in your PR description to automatically close related issues when the PR is merged.

Pull Request Templates

Create a PR template to standardize descriptions across your team:

# Create .github directory
mkdir -p .github

# Create PR template
cat > .github/pull_request_template.md <<EOF
## Description
[Describe your changes]

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Testing
- [ ] Tests pass locally
- [ ] Added new tests
- [ ] Manual testing completed

## Checklist
- [ ] Code follows style guidelines
- [ ] Self-review completed
- [ ] Documentation updated
- [ ] No new warnings generated
EOF

git add .github/pull_request_template.md
git commit -m "Add PR template"
git push

Code Review Process

Reviewing code is just as important as writing it:

As a Reviewer:
✓ Check code quality and readability
✓ Look for potential bugs or edge cases
✓ Verify tests are adequate
✓ Ensure documentation is updated
✓ Check for security vulnerabilities
✓ Consider performance implications

Review Actions:
- Comment: Ask questions or suggest improvements
- Approve: Code looks good, ready to merge
- Request Changes: Issues must be fixed before merging

Commenting on Pull Requests

GitHub provides several ways to comment:

General Comment:
Write in the conversation tab for overall feedback

Inline Comment:
Click line numbers in "Files changed" tab to comment on specific code

Multi-line Comment:
Click and drag line numbers to comment on code blocks

Suggestion:
Use suggestion syntax for direct code changes

Example of a code suggestion:

```suggestion
function calculateTotal(items) {
    return items.reduce((sum, item) => sum + item.price, 0);
}
```

This is more concise and uses modern JavaScript.

Requesting Reviewers

Assign specific people to review your PR:

# On GitHub UI:
1. Open your Pull Request
2. Click "Reviewers" in the right sidebar
3. Search and select team members
4. Click outside to confirm

# They'll receive notification to review

Best Practice: Request 1-3 reviewers depending on the complexity of changes. Too many reviewers can slow down the process.

Responding to Review Comments

When reviewers request changes:

# Make the requested changes
git checkout feature/add-contact-page
# Edit files...
git add .
git commit -m "Address review feedback: improve validation"

# Push changes (no need to create new PR)
git push

# The PR automatically updates with new commits

Communication Tip: Reply to each review comment to acknowledge feedback, even if it's just "Done ✓" or "Fixed in [commit-hash]"

Draft Pull Requests

Create draft PRs for work-in-progress code:

# When creating PR on GitHub:
1. Click "Create pull request" dropdown
2. Select "Create draft pull request"

# Benefits:
- Shows work in progress
- Prevents accidental merging
- Still allows comments and discussion
- Convert to ready-for-review when done

Merge Strategies

GitHub offers three ways to merge PRs:

1. Merge Commit (default):
- Creates merge commit with all individual commits
- Preserves complete history
- Graph shows branch structure
Command: git merge feature-branch

2. Squash and Merge:
- Combines all commits into one
- Cleaner main branch history
- Loses individual commit details
Command: git merge --squash feature-branch

3. Rebase and Merge:
- Replays commits on top of base branch
- Linear history (no merge commits)
- Cleanest history but rewrites commits
Command: git rebase main && git merge feature-branch

Important: Your repository settings determine which merge strategies are available. Admins can enable/disable options in repository settings → Options → Merge button.

Auto-merging and Requirements

Set up requirements before merging:

Common Requirements:
- Minimum number of approvals (e.g., 2 reviewers)
- Status checks must pass (CI/CD tests)
- All conversations resolved
- Branch must be up-to-date with base
- No merge conflicts

Enable in:
Settings → Branches → Branch protection rules

Closing Pull Requests

PRs can be closed without merging:

# Close PR without merging (on GitHub):
1. Scroll to bottom of PR
2. Click "Close pull request"
3. Add comment explaining why

# Common reasons:
- Changes no longer needed
- Duplicate PR
- Wrong approach
- Work abandoned

Pull Request Commands (GitHub CLI)

Manage PRs from the command line:

# Install GitHub CLI first: https://cli.github.com/

# Create PR
gh pr create --title "Add feature" --body "Description"

# List PRs
gh pr list

# View PR details
gh pr view 123

# Check out PR locally
gh pr checkout 123

# Review PR
gh pr review 123 --approve
gh pr review 123 --request-changes --body "Please fix..."

# Merge PR
gh pr merge 123 --squash

# Close PR
gh pr close 123

Practical Exercise:

Task: Create a Pull Request workflow

Create a new branch: feature/update-readme
Make changes to README.md (add a "Contributing" section)
Commit and push your changes
Create a Pull Request on GitHub
Add a detailed description using the template format
Request a review from a teammate (or yourself for practice)
Add a comment to your own PR
Merge the PR using "Squash and merge"

Expected Outcome: You'll have hands-on experience with the complete PR workflow from creation to merge.

Pull Request Best Practices

✓ Keep PRs small and focused (easier to review)
✓ Write clear, descriptive titles and descriptions
✓ Link related issues with keywords (Closes #42)
✓ Request reviews from relevant team members
✓ Respond promptly to review comments
✓ Keep PR branch up-to-date with main
✓ Resolve all conversations before merging
✓ Delete branch after merging
✓ Use draft PRs for work in progress
✓ Add screenshots for UI changes

Summary

In this lesson, you learned:

Pull Requests enable structured code review and collaboration
PR workflow: branch → commit → push → create PR → review → merge
Effective PR descriptions explain what changed and why
Code review involves commenting, approving, or requesting changes
Three merge strategies: merge commit, squash, and rebase
PR templates standardize the review process
Draft PRs are useful for work-in-progress code
GitHub CLI enables PR management from the command line

Next Up: In the next lesson, we'll explore forking repositories and contributing to open source projects!