Today I want to take the time to share with you one of my all-time favorite Github features — Draft Pull Requests. I have been actively using them in my development flow for about 12 months now.
Lately, I realized that working with draft pull requests has dramatically improved the way I structure and organize my daily engineering work as well as the efficiency with which I solve problems and deliver value for my stakeholders.
Prerequisites
I approach this topic with the assumption that you are familiar with the basic Github development flow. If that’s not the case, I suggest you take the time to get yourself familiarised with it. Trust me, you won’t regret it.
Introduction
Here is the list of characteristics applicable to normal pull requests:
- they enable you to start a discussion about the code you have committed in a branch that belongs to a specific Github repository
- other developers can review your code and give suggestions for improvements and optimizations
- once the discussion phase is over and everyone is satisfied with your proposal, you can merge your pull request into the master branch and officially add your changes to the codebase
Now, let’s have a look at the characteristics that make draft pull requests unique:
- they explicitly label your code changes as “work in progress”
- they cannot be merged into the master branch directly
The meaning of Draft PRs
When you open a pull request and set its status as “draft” you are in fact making the following statement to your teammates:
Hey, there fellow colleagues,
As you know, I am currently working on a solution to problem X. Here is the code I have written so far. Yes, I am aware my implementation is far from complete, so I am not ready to open a PR for review yet. However, I would love to get your feedback and insights on the approach I am planning to take.
After all, the sooner you get the conversation going the easier it will be to reach a consensus about the best way to code the solution.
#web-development #github #pull-request #programming
