GitHub草稿PR的含义：分享进行中的改动，尚未正式请求评审

拉取请求已经有链接、说明和代码差异，并不表示作者已经正式邀请代码所有者开展评审。GitHub的Pull requests参考页把draft pull request单独列为一种状态，用来分享仍在进行中的工作。[1] 对团队协作而言，资料可以提前出现，而正式评审请求可以发生在后一个阶段，两件事有各自的含义。

官方给草稿列出两项明确限制：草稿拉取请求不能合并，代码所有者也不会被自动请求评审。随后解释，草稿适合在不正式请求评审的情况下分享进行中的工作。这意味着草稿并非没有内容的占位页，它可以承载对改动的讨论；但看到它存在，不能推断自动评审请求已按普通可评审状态发出。

当作者准备获得反馈时，文档描述可以将草稿标记为ready for review。这一变化会向代码所有者发出评审请求。[1] 名称中的ready指向“准备接受评审”，不表示评审者已经读完，也没有表达已经批准或已经满足所有合并要求。从工作准备到请求反馈，再到实际反馈，仍是不同的协作事实。

假设作者先分享一项尚在修改的改动，之后才把它转为可评审状态。对阅读时间线的人，前一个时点说明工作已可供协作查看，后一个时点说明正式评审请求进入了文档所述阶段。这个假设不是某个仓库的运行记录；它只是说明，不能把链接首次出现的时间直接称作代码所有者收到正式请求的时间。

原页还说明，拉取请求可以在任何时候转换为草稿。由此可见，草稿与可评审并不是只在创建时决定、此后永远固定的名称。理解当前状态时，需要结合当下状态与时间线所记录的变化，而不能只凭曾经见过ready for review，就断定现在仍处于同一阶段。本篇没有进行状态切换，也没有解释组织内额外通知规则。

同一参考页把拉取请求描述为向项目提出合并改动的提议，并将讨论、评审和合并分开。草稿机制在这一协作关系中提供了更早分享工作的空间，同时保留正式请求的时点。本文依据本次读取的GitHub文档，来源没有明确首次发布日期。它解释的是平台状态语义，不把状态名称当作实际审稿结果、自动检查成绩或任何仓库的合并许可。