本文共 1006 字，大约阅读时间需要 3 分钟。

GitHub已经引入了来处理正在进行的工作场景，在这些场景中，你可能希望在代码准备好接受审查之前先打开PR或者与您的队友交流一下。

在创建新PR时，现在可以使用下拉菜单选择是创建普通的pull请求还是draft pull请求。draft pull请求与普通请求明显不同，它不能合并。你可以通过添加评论或要求其他团队成员查看并提供反馈来自由地修改draft PR。重要的是，draft PR不会每有一处修改就给所有的发通知。这是draft PR能够实际用起来的一个关键特性，否则，那些不怎么需要关注的修改也会全给他们发通知。

当你完成一个draft PR时，可以简单地把它标记为“已准备好审查”，就能将其状态设置为正常的PR了，或者如果它没有什么进展，你可以将其废弃。

一场在为这个新特性提供了更多的背景和基本原理。许多用户表示，他们已经通过在PR名称中添加“WIP”或“DO NOT MERGE”来创建draft pull 请求了。这表明，draft PR是一种将某种常见但非正式的实践进行正式化的方法。

这些PR的作用是促进讨论，开始知识共享，并向其他开发人员更清楚地介绍自己的进展情况，而不是让他们更细致地检查分支。但又是我绝对不想合并的那个。

用户tedivm指出，在开发新特性时，不能将draft pull 请求视为特性分支的替代方法。因此，所有当前的CI/CD良好实践都不受draft PR的影响。实际上，他建议你仍然创建特性分支，并在这个分支不断提交，频繁地将其推送到你的存储库，但是你可以在任何时间点创建draft pull 请求，其主要目标有两个：展示特定特性的工作已经完成和干到什么地步了；提供一种简单的方法来检查所涉及的更改，并让人们尽早对代码本身进行注释。

用户gfosco特别强调了draft PR的价值，当你参与一些大型和复杂的项目时，你无权创建分支，因此只能在自己的fork上开展工作。在这种情况下，让其他项目成员检查你的fork或分支以获得反馈实际并非一个可行的方法。相反，创建一个draft PR可以无缝地协作。

其他评论指出，他们更喜欢通过其他方法(如wiki、文档或bug跟踪器)管理此类讨论。

GitHub的draft PR并不是首创，因为GitLab已经提供了一个类似的功能，叫做。类似地，用于Android开发的原始版本管理系统也已经提供了与相同的概念。

查看英文原文：

转载地址：http://snnca.baihongyu.com/