Pull Requests

Last lesson you merged branches directly. Which works! In the real world, though, you usually don't merge your own code the second it's done. You open a "Pull Request" to propose your changes and get some eyes on them first.

What is a Pull Request?#

A Pull Request (usually just called a "PR") is your way of saying "Hey, I made some changes on my branch. Can somebody look these over before they go into main?"

It's a lot like turning in a rough draft.

1. You write your essay (make changes on a branch)
2. You hand it in for review (create a Pull Request)
3. Your teacher gives feedback (code review)
4. You make whatever fixes are needed
5. It gets accepted (merged into main)

Why Use Pull Requests?#

Code Review#

Other people get to look at your changes, and they can do a few useful things.

• Spot bugs you missed
• Suggest better ways to do stuff
• Ask questions about confusing code
• Learn from your work

Documentation#

Every Pull Request leaves a record behind.

• What changed and why
• Who reviewed it
• What discussions happened
• When it got merged

I'm a big believer in living in a glass house, meaning show your work and keep the receipts. A PR is exactly that for code, with every change and every conversation sitting out in the open.

Quality Control#

Before code ever reaches main, a few safety nets kick in.

• Automated tests can run
• Team members can approve
• Everyone knows what's being added

Creating a Pull Request#

Let's make your first Pull Request.

Step 1. Create a Branch and Make Changes#

First, make sure you've got changes sitting on a branch.

git checkout -b my-first-pr
echo "Changes for my first PR" > pr-example.txt
git add pr-example.txt
git commit -m "Add example file for PR"

Step 2. Push Your Branch to GitHub#

git push -u origin my-first-pr

After the push, Git will show you a link to create a Pull Request. Click it, or head over to GitHub yourself.

Step 3. Open GitHub#

Go to your repository on GitHub. You'll see a yellow banner saying your branch was recently pushed, with a "Compare & pull request" button. Click it!

Don't see the banner? Click the "Pull requests" tab, then "New pull request."

Step 4. Fill in the PR Details#

You'll get a form with two main boxes.

Title - A short description of your changes

• Good is "Add user login feature"
• Bad is "Changes" or "PR"

Description - Explain what you changed and why

• What problem does this solve?
• How did you solve it?
• Is there anything reviewers should know?

Step 5. Create the Pull Request#

Click the green "Create pull request" button.

What's in a Pull Request#

When you open a PR, you'll see a few tabs.

Conversation#

Where the discussion happens. Reviewers leave comments, you reply, and everyone can see the whole history.

Commits#

A list of every commit in this PR. It shows exactly which changes are being proposed.

Files Changed#

The actual code changes. Added lines show up in green and removed lines show up in red. Reviewers can leave comments on specific lines.

Reviewing a Pull Request#

Even when you're working alone, it's a good habit to review your own changes.

Step 1. Look at Files Changed#

Click the "Files changed" tab to see your changes.

Step 2. Check Your Work#

• Does everything look right?
• Did you sneak in any files by accident?
• Any typos or mistakes?

Step 3. Leave Comments (Optional)#

Click the "+" next to any line to leave a comment. That's how reviewers give feedback.

Merging a Pull Request#

Once a PR is approved (or you're ready to merge your own), here's how it goes.

Step 1. Click the Merge Button#

At the bottom of the PR, click the green "Merge pull request" button.

Step 2. Confirm the Merge#

Click "Confirm merge."

Step 3. Delete the Branch#

GitHub will offer to delete the branch. Click "Delete branch" since you don't need it anymore.

Update Your Local Repository#

After merging on GitHub, your local main branch is behind. Catch it up.

git checkout main
git pull

Now your local main matches GitHub!

PR Best Practices#

Keep PRs small

• Smaller changes are WAY easier to review
• Review big PRs in chunks if you have to

Write good descriptions

• Explain what and why
• Include screenshots for visual changes
• Link to related issues

Respond to feedback

• Don't take reviews personally (they're about the code, not you)
• Ask questions if something doesn't make sense
• Make requested changes promptly

TL;DR#

• Pull Requests let you propose changes before merging
• They make room for code review and discussion
• PRs leave a record of what changed and why
• Always write clear titles and descriptions
• After merging, delete the branch and pull the changes down locally

What's Next?#

You've got the full GitHub workflow down! GitHub can do a lot more, though. Next lesson you'll meet GitHub Actions, a way to automate stuff like running tests every time you push code...