GitHub Draft Pull 请求支持新的协作流程

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

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

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

一场在Hacker News上的讨论为这个新特性提供了更多的背景和基本原理。许多用户表示，他们已经通过在 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 已经提供了一个类似的功能，叫做WIP合并请求。类似地，用于 Android 开发的原始版本管理系统Gerrit也已经提供了与draft pull 请求相同的概念。

查看英文原文：GitHub Draft Pull Requests Enable New Collaboration Workflows