Earlier this month I wrote about about a simple GitHub workflow.

In this post, I want to talk about draft PRs - a powerful feature that can enhance your development process and team collaboration.

What are Draft Pull Requests?

Draft Pull Requests are a GitHub feature that allows you to create a pull request that’s explicitly marked as “not ready for review.” They’re perfect for when you want to:

• Share work-in-progress with your team
• Get early feedback on direction
• Track progress on larger features
• Prevent accidental merges
• Enable CI/CD testing before code review

When to Use Draft PRs

I’ve just read Michael Kaufmanns book Accelerate DevOps with GitHub.

The author argues that draft PRs should be created immediately when you start working on code.

This is a great idea if you have the fundamentals within your team up and running already.

Besides this, here’s when to use draft PRs:

1. Large Features or Refactoring

When working on substantial changes that span multiple commits or days:

# Start your feature branch
git checkout -b feature/user-authentication
git push -u origin feature/user-authentication

# Create a draft PR immediately
gh pr create --draft --title "Add user authentication system" --body "WIP: Implementing OAuth2 integration"

2. Early Feedback and Direction

Want to validate your approach before investing too much time:

# Create a draft PR with just the basic structure
gh pr create --draft --title "Proposed API structure" --body "Looking for feedback on this approach before implementing the full feature"

3. Collaborative Development

Working with team members on the same feature:

# Create draft PR for collaborative work
gh pr create --draft --title "Database schema redesign" --body "Collaborating with @teammate on this. Please add your changes to this branch."

Creating Draft PRs

Using the GitHub CLI PR option

# Create a draft PR
gh pr create --draft --title "Your title" --body "Your description"

# Or convert existing PR to draft
gh pr ready --undo

Using GitHub Web Interface

1. Push your branch to GitHub
2. Click “Compare & pull request”
3. Click “Create draft pull request” instead of “Create pull request”

Converting Between Draft and Ready

Draft → Ready for Review

# Using GitHub CLI
gh pr ready

# Or on GitHub web interface
# Click "Ready for review" button

Ready → Draft

# Using GitHub CLI
gh pr ready --undo

# Or on GitHub web interface
# Click "Convert to draft" button

Best Practices

1. Clear Communication

Always explain what you’re working on and what feedback you need:

## WIP: User Authentication System

### What's implemented:
- [x] Basic OAuth2 setup
- [x] User model
- [ ] JWT token handling
- [ ] Password reset flow

### Questions for the team:
- Should we use refresh tokens?
- What's the preferred session timeout?

### Next steps:
- Complete JWT implementation
- Add tests
- Update documentation

2. Regular Updates

Keep your draft PR updated with progress:

# Commit and push regularly
git add .
git commit -m "Add JWT token validation"
git push

# Update PR description as you progress
gh pr edit --body "Updated description with latest progress"

3. Use Labels

Add appropriate labels to your draft PRs:

# Add labels for better organization
gh pr edit --add-label "work-in-progress"
gh pr edit --add-label "needs-review"

I recently automated lable assignment using branch names, which worked great for our team.

Draft PRs vs Regular PRs

Integration with Your Workflow

Building on the workflow from my previous post, here’s how draft PRs fit in:

Enhanced Team Workflow

1. Create feature branch (same as before)
2. Create draft PR immediately (new step)
3. Work incrementally with regular commits
4. Convert to ready when complete
5. Request reviews and iterate
6. Merge and cleanup (same as before)

Common Patterns

1. Spike PRs

For experimental work or proof-of-concepts:

gh pr create --draft --title "Spike: Redis caching" --body "Testing Redis integration. Will delete if not viable."

2. Feature Flags

For features that need to be toggled:

gh pr create --draft --title "Feature: Dark mode" --body "Implementing dark mode with feature flag. Ready for testing."

3. Breaking Changes

For major refactoring:

gh pr create --draft --title "BREAKING: API v2" --body "Major API changes. Need extensive testing before merge."

Key Takeaways

Draft PRs are perfect when you want to:

• Work closer with your team
• Share work-in-progress safely
• Get early feedback without pressure
• Enable CI/CD testing early
• Prevent accidental merges
• Improve team collaboration
• Track progress on large features

Draft PRs are about collaboration. They’re a tool to make your development process more transparent and collaborative. It’s also much more fun to work together, and I feel that it makes the culture of only shipping “perfect code” less of a thing.

Happy coding!