Pull Requests (PRs): Creating a PR, PR Anatomy, and Draft PRs

The pull request is GitHub's central mechanism for proposing, discussing, and reviewing changes before they're merged — mentioned throughout earlier modules, and now the focus of deep, dedicated coverage. This lesson walks through the full process of opening a pull request, breaks down every part of its anatomy, and introduces draft PRs for signaling in-progress work.

Learning Objectives

Create a pull request proposing changes from one branch into another.
Identify and understand every major component of a pull request's anatomy.
Explain the purpose and use case of a draft pull request.
Understand what happens to a pull request once it's merged.

Key Terms to Know Before Creating a Pull Request

Pull request (PR): A GitHub feature proposing that changes from one branch (or fork) be merged into another, with built-in support for discussion, review, and automated checks before merging.
Base branch: The branch a pull request proposes to merge changes INTO (commonly main).
Compare branch (head branch): The branch containing the proposed changes, which a pull request proposes to merge FROM.
Draft pull request: A pull request explicitly marked as not yet ready for review, signaling ongoing work while still enabling early visibility and automated checks.
Status checks: Automated processes (such as CI test suites) that run against a pull request's changes, reporting pass/fail status directly within the PR.

How Creating and Structuring a Pull Request Actually Works

Creating a pull request starts with having a **branch containing the changes you want to propose** — whether that's a feature branch on a repository you have direct write access to, or a branch on your own fork (previous lessons this module). Once that branch is pushed to GitHub, navigating to the repository (or your fork) shows a prompt to open a pull request, or you can do so manually from the 'Pull requests' tab.

A pull request requires specifying two branches: the **base branch** (what you want to merge *into*, commonly `main`) and the **compare branch** (what you want to merge *from*, your feature branch). GitHub automatically computes and displays the diff between these two branches, exactly as `git diff` would show locally, but rendered in a rich, reviewable web interface.

The full **anatomy of a pull request** includes several key components:

- **Title and description**: A clear, concise title summarizing the change, and a description explaining what changed and why — often following a team's PR description template (covered in the next lesson).
- **Diff view**: The actual code changes, shown file by file, with the same `+`/`-` line format from `git diff`, but with GitHub's added ability to leave comments directly on specific lines.
- **Commits tab**: A list of every individual commit included in the pull request, letting reviewers inspect the change history in detail if needed.
- **Status checks**: Results from any automated CI/CD processes configured for the repository (such as running tests or linters), shown directly within the PR, often blocking merging until they pass if branch protection rules (Module 4) require it.
- **Reviewers and review status**: Requested reviewers, along with their review status (approved, changes requested, or commented) — the focus of a later lesson this module on code review.
- **Merge button**: Once approved and passing any required checks, a button to actually merge the pull request, with several merge strategy options (covered in a dedicated later lesson).

Sometimes you want visibility into a pull request early — perhaps to run automated checks, get early feedback, or simply signal that work is in progress — without indicating it's actually ready for a full review yet. GitHub supports this with a **draft pull request**, created by selecting 'Create draft pull request' instead of the standard option. A draft PR behaves like a normal one in most respects (diffs, checks, and comments all work normally), but is visually and functionally marked as not yet ready, and typically cannot be merged until it's explicitly marked 'Ready for review' — a small but meaningful signal that prevents a reviewer from spending time reviewing something the author doesn't consider finished yet.

Once a pull request is merged (via whichever strategy the team uses, covered later this module), its changes become part of the base branch's permanent history, and the pull request itself remains as a permanent, searchable record — including its full discussion, review comments, and diff — even though it's no longer 'open'.

Pull Request Anatomy: Visual Walkthrough

Draw a mockup of a rendered GitHub pull request page, top to bottom: 1) Title: 'Add dark mode toggle to settings page' with a 'base: main ← compare: feature/dark-mode' label underneath. 2) A row of tabs: 'Conversation | Commits | Checks | Files changed'. 3) Under 'Checks': a green checkmark row 'CI tests: passed'. 4) A diff snippet showing +/- lines with a small comment bubble icon next to one line. 5) A sidebar showing 'Reviewers: Rohit Sharma (approved)' and 'Labels: enhancement'. 6) A green 'Merge pull request' button at the bottom. Add a small badge overlay reading 'DRAFT' crossed out with an arrow labeled 'Ready for review' pointing to a normal, non-draft version of the same PR.

Pull Request Components: Quick Reference Table

Component	Purpose
Base branch	The branch changes will be merged INTO (e.g., main)
Compare/head branch	The branch containing the proposed changes
Title & description	Summarizes what changed and why, for reviewers
Diff / Files changed	Shows the actual code changes, reviewable line by line
Status checks	Automated CI/CD results (tests, linters) shown directly in the PR
Draft status	Signals work-in-progress; typically cannot be merged until marked ready

Preparing a Branch for a Pull Request: Command Syntax

# Prepare a branch locally, then push it to make it available for a pull request
git switch -c feature/dark-mode
# ... make changes, commit ...
git push -u origin feature/dark-mode

# At this point, open the Pull Request on GitHub's website:
# base: main  <-  compare: feature/dark-mode
# (Title, description, and optionally 'Create draft pull request' instead of a full PR)

# After the PR is opened, further commits pushed to the same branch
# automatically appear in the SAME pull request — no need to open a new one:
# ... make more changes ...
git add .
git commit -m "fix: address review feedback on dark mode contrast"
git push
# This new commit now appears automatically in the existing, already-open PR

Breaking Down the Pull Request Creation Example

The example shows the typical lead-up to opening a pull request: creating and pushing a feature branch. The pull request itself is created through GitHub's website, specifying `main` as the base and `feature/dark-mode` as the compare branch. The final block demonstrates an important, often-missed detail: a pull request is tied to a *branch*, not a fixed snapshot — any further commits pushed to that same branch automatically become part of the existing, already-open pull request, which is exactly how a reviewer's requested changes typically get addressed without needing to close and reopen anything.

How Pull Requests Are Used on Real Engineering Teams

Nearly all professional software teams require every change to production code to go through a pull request, even for very small fixes, as a matter of both process and (per Module 4) technically enforced branch protection.
Draft pull requests are commonly used by developers who want early CI feedback on a large, multi-day feature, without signaling to teammates that it's ready for a full code review yet.
GitHub's pull request diff view has become the de facto standard interface most developers use to review code, directly shaping conventions around commit size and PR scope (the focus of the next lesson).
Automated bots and integrations frequently interact with pull requests programmatically — commenting with test coverage reports, automatically labeling PRs based on which files changed, or requesting reviews from relevant teams.

Pull Request Interview Questions and Answers

Q1. What is a pull request, and what are its base and compare branches?

A pull request proposes merging changes from one branch into another, with built-in support for review and discussion before merging. The base branch is what you want to merge changes INTO (commonly main), and the compare (or head) branch is the one containing the proposed changes, which you want to merge FROM.

Q2. What is a draft pull request, and why would you create one?

A draft pull request is explicitly marked as not yet ready for a full review, while still enabling early visibility, automated checks, and comments. It's useful for getting early CI feedback or signaling in-progress work without indicating to reviewers that it's ready for their full attention yet.

Q3. What happens if you push additional commits to a branch after its pull request has already been opened?

Those new commits automatically become part of the same, already-open pull request — there's no need to close and reopen anything. This is how a reviewer's requested changes are typically addressed, by simply pushing new commits to the existing branch.

Pull Requests Quiz: Test Your Understanding

1. What does the 'base branch' in a pull request represent?

The branch containing the proposed new changes
The branch the changes will be merged INTO
A backup of the repository
The branch that will be deleted after merging

Answer: B. The branch the changes will be merged INTO

Explanation: The base branch is the destination — commonly main — that the pull request proposes to merge the compare (head) branch's changes into.

2. What is the primary purpose of a draft pull request?

To permanently prevent a branch from ever being merged
To signal that a pull request is not yet ready for a full review, while still allowing checks and early visibility
To automatically delete the branch once created
To hide the pull request from all repository collaborators

Answer: B. To signal that a pull request is not yet ready for a full review, while still allowing checks and early visibility

Explanation: A draft PR behaves mostly like a normal one but is clearly marked as in-progress, letting automated checks and early comments happen without implying it's ready for a complete review yet.

3. If you push a new commit to a branch that already has an open pull request, what happens?

A brand-new, separate pull request is created automatically
The new commit automatically becomes part of the existing, already-open pull request
The existing pull request is automatically closed
Nothing happens until the PR is manually refreshed by a reviewer

Answer: B. The new commit automatically becomes part of the existing, already-open pull request

Explanation: A pull request is tied to a branch, not a fixed snapshot — any further commits pushed to that branch automatically appear within the same, still-open pull request.

Common Mistakes When Creating a Pull Request

Confusing the base and compare branches, accidentally proposing changes in the wrong direction.
Opening a full, non-draft pull request for work that's clearly unfinished, prompting premature or wasted reviewer attention.
Not realizing that pushing new commits to the same branch updates the existing pull request automatically, and unnecessarily closing and reopening a new one instead.
Writing a vague or empty pull request title and description, giving reviewers no context about what changed or why.

Pull Requests: Exam-Ready Quick Notes

Pull request: proposes merging a compare/head branch INTO a base branch, with built-in review and discussion.
PR anatomy: title/description, diff, commits tab, status checks, reviewers, merge button.
Draft PR: signals not-yet-ready-for-review status; typically cannot be merged until marked 'Ready for review'.
New commits pushed to a branch automatically update its existing, already-open pull request.

Pull Requests: Key Takeaways

A pull request is fundamentally a proposal to merge one branch into another, wrapped in a rich, reviewable, discussable interface.
Understanding a PR's full anatomy — base/compare branches, diff, checks, reviewers — is essential for both creating and reviewing them effectively.
Draft pull requests provide a valuable middle ground between purely local work and a fully review-ready proposal.

Frequently Asked Questions About Pull Requests

Q1. How do I create a pull request on GitHub?

Push a branch containing your changes to GitHub, then navigate to the repository's 'Pull requests' tab (or use the prompt GitHub often shows after a push) and specify the base branch (what you want to merge into) and compare branch (your branch with the changes), along with a title and description.

Q2. What is the difference between the base branch and the compare branch?

The base branch is the destination — the branch you want your changes merged INTO, commonly main. The compare (or head) branch is the branch containing your proposed changes, which you want to merge FROM.

Q3. What is a draft pull request?

It's a pull request explicitly marked as not yet ready for a full review, while still allowing automated checks and early comments. It's useful for getting early feedback on in-progress work without prompting reviewers to spend time on something not yet finished.

Q4. Do I need to open a new pull request every time I make more changes?

No. Once a pull request is open, any additional commits you push to that same branch automatically become part of the existing pull request — there's no need to close and reopen anything.

Q5. What happens to a pull request after it's merged?

Its changes become part of the base branch's permanent history, and the pull request itself remains as a permanent, searchable record of the discussion, review, and diff, even though it's no longer open.

Summary

A pull request proposes merging changes from a compare (head) branch into a base branch, providing a rich, reviewable interface built around a diff view, commit history, automated status checks, reviewer feedback, and eventually a merge button. Creating one requires first pushing a branch containing your proposed changes, then specifying the base and compare branches through GitHub's interface. A draft pull request offers a way to gain early visibility and automated checks on in-progress work without signaling it's ready for a full review — typically blocked from merging until explicitly marked 'Ready for review'. Importantly, a pull request is tied to a branch rather than a fixed snapshot, meaning any further commits pushed to that branch automatically become part of the same, already-open pull request.