Draft PR 是什么
草稿（Draft）是 GitHub 与 GitLab 都提供的状态：把还没完成的改动先推上去，CI 照常运行，评审者能看到进展，但明确表示暂不可合并。它化解的是一对矛盾——想早点暴露构建与测试问题，又不想让评审者把半成品当成正式提交来读。
基本信息
| 对应名称 | GitHub Draft pull request / GitLab Draft merge request |
|---|---|
| 触发方式 | 创建时选 Draft，或在标题前加 Draft: 前缀 |
| CI 行为 | 照常触发流水线，提前暴露构建与测试问题 |
| 状态切换 | 点 Ready for review 转为正式评审 |
典型使用场景
- 大改动想先跑一轮 CI：早期发现编译错误与失败用例
- 方案还想听反馈：先让人看结构，避免做完才发现方向不对
- 依赖尚未合并：本改动必须等上游落地后才能转正
- 长任务分支：保持可见度，避免在本地囤积数千行未提交代码
- 实验性改动：明确告知团队不打算合并，只作讨论素材
转正前的自查
- 描述是否完整：背景、改动范围、验证方式都写清楚
- 流水线是否全绿：构建、测试、静态检查都通过
- 遗留项是否交代：注明后续由谁在哪个任务里处理
- 想被重点看的部分是否指明：替评审者标出最需要反馈的地方
状态约定与期望行为
| 状态 | 是否请求评审 | 期望行为 |
|---|---|---|
| Draft | 否 | 不进入评审队列，评论视为早期讨论 |
| Ready for review | 是 | 进入队列，按正常时限响应 |
| 长期草稿 | 否 | 作者主动关闭或更新说明，避免腐烂 |
用命令行切换状态
用命令行切换状态
gh pr create --draft --title "refactor: 拆分订单服务" --body "结构还在调整，先跑一轮 CI"
gh pr view --json isDraft # 确认当前是否为草稿
gh pr ready # 转为正式评审
gh pr ready --undo # 退回草稿状态草稿适合「先跑 CI 再定方案」的节奏：拿到真实的失败用例，比在本地反复猜测要快得多。
草稿阶段不等于免检：流水线失败同样要修，否则转正后仍然卡在最开始那一步。
长期草稿会腐烂：分支越放越难合并，团队也分不清哪些是废弃工作，最好约定转正或关闭的期限。