Module 9 Lesson 1: Writing professional Pull Requests

A Pull Request (PR) is more than just a button. It is a communication tool. A poorly written PR forces your teammates to guess what you were trying to do, which leads to slow reviews, frustration, and hidden bugs.

In this lesson, we learn the anatomy of a "Great" PR that makes your teammates' lives easier.

1. The Anatomy of a High-Quality PR

A professional PR should answer three questions for the reviewer:

What changed?
Why did it change?
How do I verify it?

The Elements of a PR Template:

Title: Short and descriptive (e.g., "Fix: Resolve memory leak in search results"). Include issue numbers if applicable.
Summary: A high-level overview of the changes.
Screenshot/Video: If your PR touches the UI, an image is worth a thousand words.
Checklist: Did you run the tests? Did you update the documentation?

2. Best Practices for PR Authors

Keep them small

No one wants to review a PR with 50 files and 2,000 lines of code. The larger the PR, the lower the quality of the review. Rule of Thumb: Try to keep PRs under 200 lines of meaningful code.

Tell a Story with Commits

Reviewers often look at your PR commit-by-commit. Use the "Squash" and "Interactive Rebase" techniques from Module 6 to ensure your history is logical and clean before you open the PR.

Self-Review First

Before you ask anyone else to look at your code, look at it yourself one more time. You will be surprised how many console logs or typos you find when you look at your own code through the lens of a PR.

graph TD
    Branch["Feature Branch"] --> PR["Create Pull Request"]
    PR --> Context["Add Summary / Why"]
    Context --> Visuals["Add Screenshots (if UI)"]
    Visuals --> Verification["Add Testing Notes"]
    Verification --> Reviewers["Assign Reviewers"]

3. Dealing with "Draft" PRs

If you are working on a complex feature and want feedback early (before the code is finished), open a Draft PR.

It clearly signals: "I'm still working, but I'd love your thoughts on the architecture."
It prevents accidental merges of unfinished code.

Lesson Exercise

Goal: The Context Challenge.

Imagine you just fixed a bug where the "Submit" button was disabled for users on Safari browsers.
Write a professional PR title and a 2-sentence summary for this change.
List 2 things a reviewer should do to verify your fix.
If you had to add a screenshot, what would it show?

Observation: You'll find that by thinking about the reviewer before you hit "Create," you build trust and speed up the entire development cycle.

Summary

In this lesson, we established:

PRs are communication tools, not just technical transactions.
A good PR includes a summary, context, and verification steps.
Small PRs get faster and higher-quality reviews.
Draft PRs are great for early architectural feedback.

Next Lesson: PRs are a two-way street. We’ll learn the "Etiquette" of being a reviewer in Lesson 2: Code review etiquette.