草稿评审请求是什么
未完成的变更先以草稿形式提出评审请求：平台支持把评审标记为草稿状态，草稿一般不会触发必需评审与合并队列，但流水线仍可运行、评论仍可进行。它适合在早期征求方向性意见，避免评审者把精力花在会返工的细节上。
基本信息
| GitHub | 创建时加草稿参数，或在页面上把评审转为草稿 |
|---|---|
| GitLab | 在标题前加草稿前缀 |
| 状态效果 | 可运行流水线、可评论，通常不可合并 |
| 转正方式 | 准备就绪后把评审标记为可评审 |
| 提示 | 两个平台的入口与命名不同，规则细节以各自文档为准 |
典型使用场景
- 早期征求方向性意见，先看设计再抠细节
- 长周期改动需要提前让团队知晓进度
- 依赖的其他分支或接口尚未就绪
- 希望先跑一轮流水线验证构建环境
- 评审未完成但想先记录讨论与决策过程
常用示例
常用示例
gh pr create --draft --fill # 创建草稿评审
gh pr ready 128 # 转为可评审
glab mr update 128 --ready # 另一个平台的对应操作
gh pr view 128 --json isDraft # 确认当前是否为草稿状态
gh pr checks 128 # 草稿状态同样可以查看流水线结果草稿与正式对照
| 项目 | 草稿状态 | 正式状态 |
|---|---|---|
| 能否合并 | 通常不可合并 | 满足规则后可合并 |
| 必需评审 | 一般不触发 | 按规则触发 |
| 流水线 | 可以运行 | 可以运行 |
| 评论讨论 | 可以正常进行 | 可以正常进行 |
草稿适合早期征求方向性意见；代码接近完成再转为正式，避免评审者把时间消耗在大量返工上。
草稿状态常被合并规则跳过，不要把未通过校验的分支直接标记为可评审，容易造成误合入。
草稿阶段就写清改动的目标、范围与验证方式，转正时评审者能立刻进入重点，不必来回追问背景。