What Is a Draft Pull Request?
A thorough, no-code-required guide to the "still cooking" version of a pull request — how it lets you share unfinished work openly, without anyone mistaking it for finished work.
Imagine an architect pinning up an early, rough sketch of a building design on the office wall, clearly labeled “concept only — not for approval,” specifically so colleagues can walk by, glance at the direction, and offer early thoughts before too much time is invested. That sketch is fundamentally different from the final, stamped blueprint submitted for official sign-off, even though both live on the same wall and follow the same general shape. A draft pull request is exactly this early sketch for code — a real, visible proposal that deliberately signals “not ready yet,” letting collaboration begin long before anything is actually finished. This post explores exactly what a draft pull request is, how it behaves differently from a regular one, and why so many teams treat it as an essential part of their workflow.
1What Is a Draft Pull Request, In Plain Words?
Let’s build a clear picture before looking at the mechanics underneath.
A pull request is a formal proposal to merge changes from one branch into another, typically opened so teammates can review, discuss, and eventually approve the work before it becomes part of the main codebase. A draft pull request is simply a pull request explicitly marked as not yet ready for that final review and approval — it exists in a clearly labeled, in-progress state that signals “here’s what I’m working on, but don’t expect this to be finished or mergeable yet.”
Functionally, a draft pull request behaves almost identically to a regular one: it shows the same file differences, can trigger the same automated checks, and supports the same commenting and discussion features. The key difference is entirely about signaling and permission — a draft pull request typically cannot be merged until it’s explicitly converted to the “ready for review” state, and it visually communicates to everyone that the work inside is still evolving.
Think of a restaurant kitchen’s “tasting” plate versus the official plate sent to a customer’s table. The tasting plate looks similar and can absolutely be examined and commented on by the head chef, but everyone in the kitchen instantly understands it isn’t meant to be served yet — that understanding alone changes how everyone treats it.
With that foundational distinction clear, let’s define the vocabulary that explains exactly how this “not ready yet” signal is implemented and used.
2The Building Blocks You Need First
A handful of terms make everything about draft pull requests far easier to follow.
Pull Request
A proposal to merge one branch’s changes into another, serving as the central place for review, discussion, and automated checks.
Draft State
A specific status a pull request can be placed in, clearly marking it as unfinished and not ready for a formal review or merge.
Ready For Review State
The state a pull request enters once its author explicitly signals the work is complete and genuinely ready for formal evaluation.
Reviewer
A person invited to examine a pull request’s proposed changes and provide feedback, questions, or formal approval.
Continuous Integration Check
An automated process that builds, tests, or analyzes the code in a pull request, reporting results regardless of whether the pull request is a draft.
Merge Block
A restriction preventing a pull request from being merged until certain conditions are met — for drafts, simply remaining in draft state is itself one such block.
Draft state and ready-for-review state are like two clearly labeled folders on a shared desk — one marked “still working on this, feel free to peek,” and the other marked “please review this properly now.” The contents can be identical; only the label, and what it invites people to do, actually differs.
With this vocabulary in hand, let’s trace exactly what happens internally as a pull request moves through these states.
3What Happens Internally, Step By Step
This is the core mechanic — a simple lifecycle that every draft pull request moves through.
Open As A Draft
A pull request is created and explicitly marked as a draft from the start, immediately signaling to everyone watching that it’s a work in progress.
Continue Committing Work
The author keeps pushing new commits to the branch, and the draft pull request automatically updates to reflect the latest changes, just like a regular pull request would.
Gather Early Feedback
Teammates can browse the changes, leave comments, and check automated results at any point, all without triggering the expectation of a full, formal review.
Mark As Ready For Review
Once the author considers the work genuinely complete, they explicitly convert the pull request out of draft state, formally inviting reviewers to evaluate it for merging.
sequenceDiagram
participant Author
participant PR as Pull Request
participant Team as Teammates
Author->>PR: Open as Draft
Author->>PR: Push additional commits
Team->>PR: Browse, comment, check CI results
Author->>PR: Mark as Ready for Review
PR->>Team: Formal review and approval can now begin
A draft pull request is not hidden from the rest of the project — it’s typically fully visible to anyone who can see the repository. The “draft” label changes expectations and merge permissions, not visibility itself.
4The Bigger Picture: Data Flow And Lifecycle
Zooming out from one pull request, let’s see how draft status fits into the broader rhythm of collaborative development.
In an actively developed project, it’s common for several draft pull requests to exist simultaneously alongside regular, ready-for-review ones. Each draft represents work that’s genuinely in motion — being actively shaped, adjusted, and refined — while the ready-for-review pull requests represent work that’s paused specifically to await a decision. This mixture gives a project a realistic, honest picture of exactly where every active effort actually stands.
flowchart LR
A[New work begins] --> B[Opened as Draft Pull Request]
B --> C[Ongoing commits and early feedback]
C --> D{Work genuinely complete?}
D -- Not yet --> C
D -- Yes --> E[Marked Ready for Review]
E --> F[Formal review and approval]
F --> G[Merged into main branch]
This lifecycle also supports a healthy back-and-forth: a pull request marked ready for review can, if a reviewer raises significant concerns, be converted back into a draft while the author addresses them, then re-marked as ready once again. The state isn’t a one-way door — it’s a flexible signal that can shift as understanding of the work evolves.
Why This Flexibility Matters
Being able to move a pull request back into draft state, rather than closing and reopening it, preserves the entire discussion history and commit record in one continuous place, avoiding fragmented conversations across multiple pull requests.
5Draft Pull Request vs Regular Pull Request
Placing these two side by side makes the practical differences immediately clear.
| Aspect | Draft Pull Request | Regular Pull Request |
|---|---|---|
| Signals work is finished | No | Yes |
| Can be merged directly | No, must be marked ready first | Yes, once approved |
| Visible to the team | Yes | Yes |
| Triggers automated checks | Yes | Yes |
| Invites formal review by default | No | Yes |
| Supports comments and discussion | Yes | Yes |
A regular pull request is like formally submitting an assignment for grading. A draft pull request is like showing your professor your in-progress notes during office hours — genuinely useful for early feedback, but nobody’s expecting you to have submitted your final answer yet.
6Draft Pull Requests vs The Older “WIP” Convention
Before draft pull requests existed as a dedicated feature, teams relied on an informal convention worth understanding for context.
Long before a formal draft state existed, teams commonly signaled unfinished work by simply adding “WIP” — short for “work in progress” — directly into a pull request’s title. This worked reasonably well as a visual cue, but it depended entirely on humans remembering to add it, remembering to remove it later, and never actually prevented anyone from accidentally merging the pull request while it still said “WIP” in the title.
The Old “WIP” Title Convention
- Purely a visual, human-maintained signal with no technical enforcement.
- Nothing technically prevents an accidental merge, even with “WIP” clearly in the title.
- Easy to forget to remove once work is actually finished.
The Dedicated Draft State
- A genuine, enforced status recognized by the platform itself.
- Merging is technically blocked until the state is explicitly changed.
- Automatically visible through dedicated visual indicators, not just a title convention.
Prefer the dedicated draft state over title conventions whenever it’s available — the enforced merge block genuinely prevents the exact accident the “WIP” title was only ever trying to warn against.
7Why Teams Actually Use Draft Pull Requests
Beyond the mechanics, a few genuine motivations explain why this feature has become so widely adopted.
Early Directional Feedback
Opening a draft early lets an author check whether their overall approach makes sense before investing significant additional time refining the details.
Visibility Into In-Progress Work
Teammates and managers can see, at a glance, what’s actively being worked on across the team, without needing separate status updates or meetings.
Running Checks Before Finishing
Automated checks running continuously against a draft catch problems early, letting an author fix issues incrementally rather than discovering a pile of them all at once at the end.
Collaborative Pairing Across Time Zones
A draft pull request lets one teammate pick up exactly where another left off, with full visibility into the current state and history of the work.
8Converting Between Draft And Ready States
Moving between these two states is intentionally simple, but understanding what each transition actually does matters.
Draft → Ready For Review
An explicit action taken by the author once they consider the work complete, formally inviting review and unlocking the ability to merge once approved.
Ready For Review → Draft
Available if significant rework is needed after review has already begun, cleanly resetting expectations without losing any existing history or discussion.
Neither transition affects the underlying branch, its commits, or its history in any way — it purely changes the pull request’s status and the expectations attached to it. This makes converting back and forth a low-risk, purely organizational action rather than something that could disrupt the actual code.
Flipping between draft and ready states is like flipping a simple sign on an office door between “please knock, work in progress” and “come on in, ready for feedback” — the room and everything inside it stays exactly the same.
9Collaboration Benefits: Visibility Without Commitment
One of the quieter, but genuinely powerful, benefits of draft pull requests is how they reshape team communication.
Without a dedicated draft state, developers often face an uncomfortable choice: either keep unfinished work entirely private until it feels “ready,” missing out on early feedback, or open a regular pull request and risk it being reviewed, or even merged, before it’s truly finished. Draft pull requests remove this tension entirely, offering a genuinely safe middle ground — full visibility and collaboration, with zero risk of premature review or merging.
Reducing Duplicate Effort
When teammates can see a draft in progress, they’re far less likely to accidentally start similar work in parallel, since the ongoing effort is already visible and clearly signaled.
Encouraging Earlier, Smaller Conversations
Feedback offered on a draft tends to be lighter and more exploratory, catching directional issues early rather than only surfacing detailed concerns once the work is fully polished and harder to change.
10Monitoring: How CI Checks Behave On Draft Pull Requests
Automated checks don’t pause just because a pull request is marked as a draft — understanding this is genuinely useful.
Checks Still Run
Most automated build, test, and quality checks continue to run against a draft pull request exactly as they would against a regular one.
Results Are Still Visible
Pass or fail results are shown directly on the draft pull request, giving the author ongoing, real-time signals about the health of their in-progress work.
Merge Remains Blocked Regardless
Even if every check passes perfectly, the pull request still cannot be merged while it remains in draft state, since that block is independent of check results.
Use the continuous check results on a draft as an early-warning system, fixing small issues as they appear rather than letting them accumulate until the pull request is finally marked ready for review.
11Advantages And Trade-offs
Like any tool, draft pull requests bring genuine strengths alongside a few things worth being mindful of.
Advantages
- Provides a technically enforced safeguard against premature merging, unlike informal title conventions.
- Enables early, low-pressure feedback that can save significant rework later.
- Gives the whole team honest visibility into what’s actually in progress at any moment.
- Runs the exact same automated checks as a regular pull request, catching issues early.
- Preserves full discussion and commit history across state changes, avoiding fragmented conversations.
Disadvantages / Trade-offs
- Doesn’t hide work from the rest of the repository, which may not suit every situation.
- Can be left in draft state indefinitely if a team doesn’t build the habit of marking work ready promptly.
- Adds one more status for teams and tools to account for when tracking overall progress.
- Provides no protection on its own without a team culture that respects what the draft label actually means.
12Staying Safe: Risks Worth Understanding
Draft pull requests are generally low-risk, but a few situations deserve genuine attention.
Public Visibility Of Unfinished Code
On public repositories, a draft pull request’s contents are typically visible to anyone, including incomplete or experimental code you may not want widely seen yet.
Accidentally Exposed Secrets
Because drafts are treated like real pull requests, accidentally committing sensitive information into one carries the same exposure risk as doing so in a regular pull request.
Forgotten, Stale Drafts
A draft left untouched for a very long time can quietly fall out of sync with the main branch, accumulating conflicts that make it harder to finish later.
Misplaced Trust In The Draft Label Alone
The draft state blocks merging, but it does not by itself prevent reviewers from being pinged, notifications from firing, or automated tools reacting to the pull request, depending on configuration.
Never treat a draft pull request as a safe place to intentionally commit secrets or sensitive data “just temporarily.” The same handling rules that apply to any pull request apply here in full.
13Design Patterns And Anti-patterns
A few recurring habits separate teams that use draft pull requests effectively from teams that let the feature quietly go to waste.
Healthy Pattern: Open Early, Narrate Progress
Opening a draft right at the start of meaningful work, and occasionally leaving brief comments about direction, keeps the whole team naturally informed without extra meetings.
Healthy Pattern: Mark Ready The Moment It’s True
Converting to ready-for-review the instant work is genuinely finished keeps the signal meaningful and avoids reviewers wasting time on something still actively changing.
Problem
Leaving a pull request in draft state for weeks after the work is actually finished, simply out of habit or forgetfulness.
Why It’s Harmful
Finished work sitting unreviewed delays its benefit to the team and can quietly accumulate merge conflicts the longer it waits, undermining the very momentum draft pull requests are meant to support.
Correct Approach
Build the habit of marking a pull request ready for review the moment it’s genuinely complete, treating that transition as a deliberate, prompt action rather than an afterthought.
Problem
Using draft state as an excuse to skip good commit hygiene or clear communication, assuming “it’s just a draft” means quality doesn’t matter yet.
Why It’s Harmful
Since drafts are fully visible and reviewable, sloppy history or unclear intent still confuses teammates trying to offer genuinely useful early feedback.
Correct Approach
Treat a draft as a real, visible piece of communication with the team — clear commits and a short description of intent go a long way, even while the work itself is still evolving.
14Best Practices And Common Mistakes
A short list of habits keeps draft pull requests genuinely useful, rather than becoming just another ignored status.
Open Drafts Early, Not Just At The End
The earlier a draft is opened, the more genuine value it provides through early feedback and visibility, rather than becoming a formality right before finishing.
Write A Short Description Of Intent
Even in draft form, a brief explanation of what you’re trying to accomplish helps early feedback stay relevant and focused.
Pay Attention To Continuous Check Results
Treat failing checks on a draft as genuine signals to address, rather than something to ignore until the pull request is marked ready.
Never Treat Draft State As A Security Boundary
Handle sensitive information with exactly the same caution in a draft as you would in any regular, fully reviewed pull request.
Mark Ready Promptly Once Finished
Don’t let a genuinely finished draft linger — convert it the moment it’s truly ready, keeping the whole team’s signals meaningful and current.
15How Real Teams Use Draft Pull Requests
This isn’t a niche feature — it’s woven into the daily collaborative habits of modern software teams.
Large Feature Work Spanning Multiple Days
A developer tackling a substantial feature opens a draft on day one, letting the team watch the approach take shape gradually, rather than seeing it appear fully formed at the very end.
Onboarding New Contributors
New team members often use drafts to safely ask “am I on the right track?” early in their first few contributions, getting reassurance before investing significant additional effort.
Cross-Team Coordination
Teams working on interdependent pieces of a larger effort use draft pull requests to signal progress to each other, coordinating timing without needing separate status meetings.
16Frequently Asked Questions
Yes, typically anyone who can already see the repository can also see a draft pull request within it, since draft state changes merge permissions and expectations, not visibility.
No, merging is technically blocked while a pull request remains in draft state, requiring an explicit conversion to ready-for-review before a merge can happen.
Yes, in most configurations checks run exactly as they would on a regular pull request, giving the author ongoing feedback throughout the work.
Yes, this is a supported and genuinely useful transition when significant additional work turns out to be needed after review has already started.
No — draft status is about readiness for review and merging, not about hiding the pull request from others. Privacy depends entirely on the repository’s own visibility settings, separate from draft status.
17Summary and Key Takeaways
A draft pull request is a genuine, visible proposal explicitly marked as not yet ready for formal review or merging, giving teams a technically enforced way to share in-progress work openly. It behaves almost identically to a regular pull request — supporting comments, discussion, and automated checks — but blocks merging until the author deliberately signals the work is complete. Replacing older, purely informal conventions like adding “WIP” to a title, draft pull requests provide genuine early visibility, safer collaboration, and a cleaner, more honest picture of what’s actually in progress across a team at any given moment.
Key Takeaways
- A draft pull request is fully visible and reviewable, but technically blocked from being merged until marked ready.
- It replaces older, purely informal “WIP” title conventions with a genuinely enforced status.
- Automated checks continue running on drafts, giving ongoing, real-time feedback throughout the work.
- Converting between draft and ready states is reversible and preserves the full history and discussion in one place.
- Draft pull requests improve team visibility and reduce duplicate effort, without exposing anyone to premature review pressure.
- Draft status is not a security boundary — sensitive information should never be treated as “safe” within one.
- Opening early and marking ready promptly are the two habits that make this feature genuinely valuable rather than just another status.