Skip to main content

Pull Requests and Code Review Process

Now that you're comfortable with Git fundamentals and GitHub basics, it's time to learn about one of the most powerful collaboration features: pull requests. This lesson will transform you from a solo developer into an effective team contributor.

Learning Goals:

  • Understand what pull requests are and when to use them
  • Learn how to create and manage pull requests on GitHub
  • Master the code review process and best practices
  • Handle feedback and merge pull requests successfully

What Are Pull Requests?​

A pull request (PR) is a proposal to merge changes from one branch into another. Think of it as saying: "I've made some changes in this branch, and I'd like you to review them before they become part of our main codebase."

Pull requests serve several important purposes:

  • Code Review: Team members can examine changes before they're merged
  • Discussion: Developers can discuss implementation details
  • Continuous Integration: Automated tests can run on the proposed changes
  • Documentation: PR descriptions and comments create a history of why changes were made
tip

Even if you're working alone, creating pull requests for your own features is excellent practice. It helps you review your own code and maintain good habits for when you collaborate with others.

Creating Your First Pull Request​

Let's walk through creating a pull request for a simple feature. Imagine you've been working on a login feature in a separate branch.

Step 1: Create and Push Your Feature Branch​

Terminal
# Start from your main branch
git checkout main
git pull origin main

# Create and switch to a new feature branch
git checkout -b feature/user-login

# Make your changes (let's simulate this)
echo "// Login functionality" >> login.js
git add login.js
git commit -m "Add basic login functionality"
git push origin feature/user-login

Step 2: Create the Pull Request on GitHub​

  1. Go to your repository on GitHub
  2. You'll see a yellow banner suggesting you create a pull request from your recently pushed branch
  3. Click "Compare & pull request"

Step 3: Fill Out the Pull Request Template​

A good PR description should include:

  • Title: Clear and descriptive (e.g., "Add user login functionality")
  • Description: What changes were made and why
  • Related Issues: Links to any GitHub issues this addresses
  • Testing: What testing was performed
PR Description Example
## What does this PR do?
Adds user login functionality with email and password authentication.

## Related Issues
Fixes #42

## Testing
- [x] Manual testing with valid credentials
- [x] Manual testing with invalid credentials
- [ ] Unit tests added (will follow in separate PR)

The Code Review Process​

Code review is where the real collaboration happens. Let's explore what makes an effective review.

Giving Constructive Feedback​

When reviewing someone else's code:

Good Review Comment
// Instead of: "This code is wrong"
// Try: "Consider adding input validation here to handle edge cases"

// Instead of: "Fix the styling"
// Try: "The button padding seems inconsistent with our design system. Can we use the standard spacing variables?"

Receiving Feedback Gracefully​

When your code is being reviewed:

  • Don't take feedback personally - it's about the code, not you
  • Ask clarifying questions if you don't understand a suggestion
  • Explain your reasoning when you disagree
  • Thank reviewers for their time and insights
note

A good code review should take 5-30 minutes. If it's taking longer, consider breaking the PR into smaller, more focused changes.

Advanced Pull Request Features​

Requesting Specific Reviewers​

You can request reviews from specific team members:

Terminal
# Or do this through the GitHub UI
gh pr create --base main --head feature/user-login --reviewer team-member-1,team-member-2

Using Review Assignments​

# Request reviews from specific individuals
gh pr edit 123 --add-reviewer alice,bob

Linking Issues Automatically​

GitHub can automatically close issues when PRs are merged:

PR Description
Fixes #123
Closes #124
Resolves #125

Reviewing and Merging Pull Requests​

Conducting a Thorough Review​

When you're assigned to review a PR:

  1. Understand the Context: Read the PR description and linked issues
  2. Review the Code: Look for:
    • Logic errors
    • Security issues
    • Performance concerns
    • Code style consistency
  3. Test the Changes: Check out the branch and test locally if needed
  4. Provide Actionable Feedback

Merge Strategies​

GitHub offers several merge options:

  • Create a merge commit: Preserves full history (recommended)
  • Squash and merge: Combines all commits into one
  • Rebase and merge: Linear history without merge commits
Checking Merge Status
# Check if the PR can be merged cleanly
gh pr view 123 --json mergeStateStatus

Common Pitfalls​

  • Too Large PRs: Keep PRs focused and under 400 lines when possible
  • Vague Descriptions: Always explain the "why" behind changes
  • Ignoring CI Results: Never merge PRs with failing tests
  • Rushing Reviews: Take time to understand the changes thoroughly
  • Personal Criticism: Focus on code, not the person who wrote it
  • Missing Tests: New features should include appropriate tests
  • Not Addressing All Comments: Ensure all feedback is acknowledged or addressed

Summary​

Pull requests are the heart of collaborative development on GitHub. They enable code review, discussion, and quality control before changes reach your main codebase. Remember to:

  • Create focused, well-described pull requests
  • Review code constructively and thoroughly
  • Use GitHub's features like requested reviewers and issue linking
  • Keep PRs manageable in size
  • Always ensure tests pass before merging

Quiz​

Pull Requests and Code Reviews – Quick Check

What is the primary purpose of a pull request?

Question 1/5