GitHub introduces draft pull requests that allow developers to discuss code before applying
GitHub has just launched the ability to create ‘draft’ pull requests in work-in-progress scenarios where you might want to open a pull request or start a discussion with other collaborators before applying all the code changes.
“At GitHub, we’ve always felt that you should be able to open a pull request to start a conversation with your collaborators as soon as your brilliant idea or code is ready to take shape. Even if you end up closing the pull request for something else, or refactoring the code entirely, a good pull request is as much about collaboration as it is about code,” said GitHub’s Luke in a blog post.
“But what if you want to signal that a pull request is just the start of the conversation and your code isn’t in any state to be judged? Perhaps the code is for a hackathon project. You have no intention of ever merging it, but you’d still like people to check it out locally and give you feedback. Or perhaps you’ve opened a pull request without any code at all in order to get the discussion started.”
Developers can mark a pull request as a draft simply by clicking the drop-down arrow next to the button that originally pulled the request. When a user opens a pull request, a dropdown arrow appears next to the “Create pull request” button. Users can toggle the dropdown arrow whenever they want to create a draft instead.
A draft pull request is styled differently to clearly indicate that it’s in a draft state and cannot be merged with the main database. However, a draft pull request can be freely modified by adding comments or requiring other team members to have a look at it and provide their feedback.
Once the draft is ready, the status can be changed to “Ready for review” near the bottom of the pull request to remove the draft state and allow merging according to the project’s settings. Also, if the project uses a CODEOWNERS file in the user’s repository, the drafts will not send automatic notifications to those reviewers until it is marked as ready for review.
The new feature was met with mixed reviews from users in a discussion on Hacker News. One of the users citing saving of time said, “It saves a lot of wasted effort by exploring the problem domain collaboratively before development begins.”
On the other hand, another user citing its ineffectiveness commented, “Someone suggested this on my team. I personally don’t like the idea because these policies often times lead to bureaucracy and then nothing getting released. It is not that I am against thinking ahead but if I have to in details explain everything I do, then more time is spent documenting than actually creating which is the part I enjoy.”