Why Draft PRs Are a Developer’s Secret Weapon
By sharing in-progress work via draft pull requests, you can invite early feedback, integrate seamlessly with CI tools, and foster trust and transparency within your team.
Audience: software developers, team leads
TL;DR By sharing in-progress work via draft pull requests, you can invite early feedback, integrate seamlessly with CI tools, and foster trust and transparency within your team.
Draft pull requests (PRs) might seem like a small feature—essentially just an “in-progress” label; however, their impact on the software development life cycle is anything but minor. By inviting early feedback, enhancing team transparency, and integrating seamlessly with continuous integration (CI) workflows, draft PRs have become one of my favourite tools for writing high-quality code and fostering collaboration.
The Evolution of My Workflow
I have a habit of pushing my work to the remote repository almost reflexively—after nearly every commit (and I commit often). This stems from a former boss’s emphasis on the importance of backups.
At a recent job, a co-worker tapped me on the shoulder one morning to point out something he’d noticed in my code. I hadn’t even opened a PR yet, so I was surprised—how had he seen it? Turns out, he’d been browsing other developers’ branches in the repository. That was my light bulb moment: frequent pushes didn’t just serve as backups—they made my work visible.
I started opening a PR as soon as I had a single commit.
Once I realised that developers browsed the repository in this way, I set out to capitalise on it; I wanted to make sure my branches were the first ones they noticed. To make a branch easy to find, I would open a PR as soon as the branch had a single commit. I didn’t care if my code wasn’t ready for review yet; I wanted it visible! I wanted all the free reviews.
I stumbled across GitHub’s draft pull request feature.
While sharing my “free feedback” trick with a co-worker, she told me about GitHub’s draft PR feature—jackpot! Now, when I opened a PR with a single commit, I could mark it as a draft in order to avoid miscommunication. Clear communication is my favourite thing, and the draft PR feature makes it effortless.
I incorporated continuous integration more heavily into my workflow.
Pushing to a GitHub PR triggered our CI pipeline to run a suite of scripts and tests on that branch. By opening a draft PR early, I ensured that every push triggered those checks, giving me instant and comprehensive feedback on my changes. This became a staple part of my workflow: I could code confidently, knowing any failed checks after my initial push were caused by my work—not pre-existing issues on the main branch. No more time wasted tracking down whether a test failure was my fault or not.
Colleagues no longer had to blindly trust I was on track.
Draft PRs gave my team lead and my colleagues full transparency. If I was troubleshooting and it was taking longer than expected, they could see exactly what I was working on—no mystery, no need to have blind faith in my lack of visible progress. My work was all out in the open. This visibility built trust and also allowed teammates to quickly jump in if I needed a second set of eyes.
My coding habits improved.
Wanting my work to be reviewable at any stage pushed me to improve my coding habits. I started writing clearer commit messages and cleaner code from the get-go. I left notes in my code to flag areas that weren’t complete (for sneaky reviewers and, let’s be honest, my future self) and added context to my PR descriptions for anyone curious enough to peek. These habits paid off: my work was always easy to set aside, revisit, or hand off. Every PR captured my overall plan, next steps, and any debugging notes—perfect for a sneaky review or a smooth transition.
Benefits of Draft PRs
Draft PRs are more than just a label—they’re a tool for better collaboration, visibility, and productivity. (But also, they are just a label.) Here’s why they’re invaluable for developers and teams:
They encourage early feedback: Sharing in-progress work invites input from colleagues, allowing you to catch issues and refine your approach without a formal code review.
They integrate seamlessly with CI tools: Draft PRs can trigger early CI checks, catching problems tied to your changes while avoiding time wasted troubleshooting pre-existing issues.
They improve team trust: Draft PRs make your progress visible, giving your team confidence in your workflow and creating opportunities for collaboration.
They boost personal productivity: Having your work visible at all times provides motivation to write clearer commit messages, add notes, and maintain context in your PRs. This makes your work easy to revisit, set aside, or hand off.
Encouraging Adoption: Tips for Using Draft PRs
Sharing in-progress work can feel intimidating, especially if you’re used to keeping your code private until it’s polished. Here are a few tips to help you ease into this new habit and encourage a team culture of transparency and collaboration.
Overcoming Initial Hesitations
Feeling protective of incomplete code is natural. But remember, draft PRs are explicitly labelled as “in-progress”, which sets expectations.
If you’re hesitant, start small by getting into the habit of pushing regularly to the remote repository. Your work becomes visible, but it’s unlikely anyone will be looking closely. This gives you time to adjust to sharing in-progress work without the pressure of immediate scrutiny. Code, commit messages, and notes don’t have to be polished at this point. This is in-progress work: unpolished is the expectation!
Once you’re comfortable with regular pushes, the next step is to try a draft PR. You don’t have to open one the minute you have a single commit, but try opening one earlier than you’d usually open a PR. How about when you’re halfway through the task, or when you’ve got the code working but not yet polished?
As your confidence grows, you can gradually open draft PRs earlier and earlier in your workflow.
The final step is to start being vocal about your new way of working. Let your teammates know that your work is always visible. Invite them to check out your work anytime, fostering an open environment for feedback.
Encouraging a Culture of Feedback and Transparency
Draft PRs can help shift your team toward greater openness and collaboration, but it’s essential to set the tone as positive and constructive. If you’re in a leadership role, frame draft PRs as low-stakes, collaborative spaces where work can evolve with input. Encourage feedback to focus on learning and support rather than critique.
Lead by example by actively participating in your team’s draft PRs. Offering thoughtful, constructive feedback shows your team that early reviews are opportunities, not criticisms. Over time, this approach can create a culture of “in-progress” transparency, where collaboration and trust thrive. Draft PRs aren’t just a tool for individual productivity—they can be a cornerstone for better teamwork.
Draft PRs Across Different Platforms
Draft pull requests are a widely adopted feature across many repository management platforms, including GitHub, GitLab, Bitbucket, and Gerrit Code Review. By understanding how draft PRs work on your preferred platform, you can incorporate them into your workflow. Skip to the section below that corresponds to your preferred platform! (If your platform isn’t included, please reach out so I can add it!)
GitHub
GitHub introduced its draft PR feature in 2019. To create a draft PR, simply select the “Create draft pull request” option when opening a new PR. Draft PRs are visually marked with a “Draft” label, making their status clear to reviewers. Note that this feature is not available in all repositories—see the table below for details on where it’s supported.
Plan: GitHub Free, GitHub Pro
Account: Personal or organisation
Public repositories have the draft PR feature. Private repositories do not.
Plan: GitHub Team, GitHub Enterprise
Account: Personal or organisation
Both public and private repositories have the draft PR feature.
The draft PR feature is also available on legacy plans, but only for public repos. (https://github.com/orgs/community/discussions/23478)
Learn more about GitHub’s draft PRs here: https://github.blog/news-insights/product-news/introducing-draft-pull-requests/
GitLab
In GitLab, draft PRs are known as “draft merge requests.” You can create a draft merge request by adding "Draft:", "[Draft]", or "(Draft)" to the beginning of the merge request title or by selecting the draft option in the interface if your version of GitLab supports it.
This feature was introduced in July 2020, in GitLab 13.2. It replaced the previous “Work-In-Progress (WIP)” feature to better align with industry terminology. The draft merge request feature is available on every GitLab plan (Free, Premium, and Ultimate), in both public and private repositories. How wonderful!
Learn more here: https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html
Bitbucket
Bitbucket offers draft pull requests, but only with their Data Center option. The draft pull request feature was introduced to BitBucket Data Center in version 8.18 back in February 2024 (which seems very late). So it seems likely that it might be introduced to Bitbucket Cloud sometime in the near future.
Bitbucket offers two deployment options—Cloud and Data Center—each tailored to different organisational needs. The two options have completely separate pricing structures and feature sets. Bitbucket Cloud has a Free Plan, a Standard Plan, and a Premium Plan. My understanding is that none of these plans include the draft pull request feature. However, there are third-party plugins that supposedly offer similar functionality, namely Flowie. I haven’t tried out this tool myself yet, so I’ll need to experiment at some point!
More info on Bitbucket’s draft PRs here: https://confluence.atlassian.com/bitbucketserver/draft-pull-requests-1354498120.html
More info on Flowie here: https://marketplace.atlassian.com/apps/1231101/flowie?tab=overview&hosting=cloud
Gerrit Code Review
Gerrit is a free resource and so does not have any plans or subscription tiers. Draft PRs are available to all users. Their terminology for draft PR is “work in progress”. They have a really cool command line option for marking a change as a work-in-progress. You simply append “%wip” to your command:
git push origin evh_branch%wipIsn’t that cool?! Later, when you want to indicate that the change is ready for review, you can append "%ready":
git push origin evh_branch%readyYou can also toggle between "work-in-progress" and "ready" in the web UI. You aren’t limited to the command line.
More info on Gerrit Code Review WIPs here: https://gerrit-review.googlesource.com/Documentation/intro-user.html#wip
Conclusion
Draft pull requests have become an invaluable part of my development process. By opening a draft PR early in my workflow, I’m setting up my work for early feedback and also building a more collaborative and transparent environment for my team. Draft PRs create opportunities for “free advice” from colleagues and provide a stable foundation for continuous integration checks. They also play a key role in fostering team trust—when my work is accessible and visible, it’s easier for others to support me, offer guidance, and stay in sync with my progress.
Whether you’re using GitHub, GitLab, Bitbucket, Gerrit Code Review, or another platform, draft PRs are a powerful tool for making in-progress work visible and inviting collaboration in a low-stakes way. If you haven’t tried draft PRs yet, consider incorporating them into your workflow. They’re a simple but effective way to improve both individual and team productivity, paving the way for stronger communication and a smoother code review process later on.
💬 What Do You Think?
I’d love to hear your thoughts! Did I get something wrong about the tools I mentioned (GitHub, GitLab, Bitbucket, or Gerrit)? Do you disagree—or maybe strongly agree—with anything I’ve said?
Whether you’ve got corrections, suggestions, or just want to share your own experiences with draft PRs, I’m all ears. Drop a comment below or reach out to me directly at erin@thepassionatecoder.com. Your feedback makes these conversations richer and helps us all learn and grow!