Skip to main content
What is a draft pull request? A draft pull request (draft PR) is a GitHub pull request state indicating the contribution is a work in progress. It gives teams early visibility into proposed changes—allowing design and integration feedback—while preventing the PR from being treated as ready to merge. Key characteristics of a draft pull request
  • Non-mergeable state
    Draft PRs are locked and cannot be merged until the author converts them to a ready-for-review state. This prevents accidental merges into the base branch.
  • Suppressed notifications
    Creating a draft PR does not automatically notify repository owners or designated reviewers. This reduces unnecessary review pings and prevents review fatigue.
  • Visual indicators
    Draft PRs are visibly labeled with a draft badge and use a distinct gray icon in lists so reviewers can quickly distinguish them from active PRs.
Summary table
The image is an infographic titled "Draft Pull Request," highlighting three key characteristics: non-mergeable state, suppressed notifications, and visual indicators, each represented by arrows with icons.
Converting a draft pull request to “Ready for review” is a deliberate, manual step. Only after that conversion will the PR become mergeable and trigger reviewer notifications.
Why use a draft pull request?
  • Early feedback
    Draft PRs let you share high-level direction, architecture, or approach so teammates can give early feedback before you finalize the implementation. This early collaboration helps catch design issues and reduces rework.
  • CI/CD validation
    Most repositories run continuous integration checks (builds, tests, linters) on draft PRs. That lets authors verify the code compiles and tests pass as they iterate, reducing trivial failures when the PR is later marked ready for review.
The image explains the benefits of using draft pull requests, highlighting early feedback loops and CI/CD validation.
Best practices
  • Use draft PRs for early design reviews and integration checks, not for finalized changes.
  • Update the PR description as work progresses so reviewers understand the current scope.
  • Convert to “Ready for review” only when the implementation and CI results are stable.
Links and references

Watch Video