Skip to content

How to Open a Pull Request on GitHub

Pull requests are the heart of collaboration on GitHub. Here’s how to create one from start to finish.

Step 1: Create a Branch

# Start from the latest main
git checkout main
git pull origin main

# Create a feature branch
git checkout -b fix-login-bug

Step 2: Make Changes

# Work on your changes
git add .
git commit -m "Fix login bug when email contains special characters"

# Push to GitHub
git push -u origin fix-login-bug

Step 3: Open the Pull Request

  1. Go to your repository on GitHub
  2. Click “Pull Requests” → “New Pull Request”
  3. Select your branch (fix-login-bug) against main
  4. Fill in the PR template

Writing a Good PR Description

## Description
Fixed a bug where users with special characters in their email
couldn't log in.

## Root Cause
The email validation regex didn't allow the '+' character.

## Changes
- Updated email regex in `validators.py`
- Added test cases for special characters

## Testing
- ✅ Unit tests pass
- ✅ Manual login tested with emails containing +, &, = 
- ✅ All existing tests pass

## Related Issues
Closes #142

PR Best Practices

Keep PRs Small

  • One PR per feature or fix — don’t bundle unrelated changes
  • Fewer than 400 lines is a good target
  • Split large changes into multiple PRs

Write Good Commit Messages

✅ feat: add user profile page
✅ fix: correct email validation regex
✅ refactor: extract auth logic into service
❌ update stuff
❌ fix
❌ changes

Respond to Reviews

  1. Fix the requested changes
  2. Push a new commit
  3. Reply to the comment: “Fixed in abc123”

Don’t resolve conversations yourself — let the reviewer mark them as resolved.

Reviewing a PR

When reviewing someone else’s PR:

✅ "The logic looks correct. Consider extracting this into a helper."
✅ "Can we add a test for the edge case where `data` is None?"
✅ "This change would affect the caching layer. Have we tested for that?"

Focus on: correctness, security, performance, maintainability, test coverage.

Merging Options

MethodHistoryUse When
Create a merge commitPreserves full historyDefault for most teams
Squash and mergeSquashes all commits into oneCleaning up messy history
Rebase and mergeLinear history, no merge commitsYou want a clean git log

PR Checklist Before Submitting

  • Code compiles / tests pass
  • No debug code, print statements, or TODO comments
  • Meaningful variable/function names
  • Error handling added where needed
  • Documentation updated if API or behavior changed
  • No secrets or credentials committed
  • PR description explains what and why

Common PR Mistakes

❌ PR with 50 files changed (too large)
❌ No description ("Fixed bug" tells me nothing)
❌ Ignoring review comments
❌ Force pushing after review (overwrites reviewer progress)
❌ Merging without approval
❌ Resolving conversations without the reviewer agreeing

Related: Learn Git branching strategies and merge vs rebase.