/pr 命令让你在终端完成 PR 全生命周期管理：创建 PR、处理 Review 意见、解决合并冲突、修复 CI 失败。/pr auto 更是全自动模式——创建 PR 后循环执行所有修复流程，直到所有检查通过。

GitHub Copilot CLI /pr 命令：在终端管理 Pull Request

前提条件

• 当前目录是 GitHub 托管的 Git 仓库
• 已通过 Copilot CLI 认证

查看 PR 状态

/pr
# 或
/pr view

显示当前分支的 PR 状态：是否有待处理的 Review 意见、CI 状态、冲突等。

/pr view web

在浏览器中打开 PR 页面。

创建 PR

/pr create

Copilot 会确保本地提交推送到远程分支，然后自动创建 PR。

支持追加自定义指令：

/pr create 标题加上 "Project X: " 前缀
/pr create 把所有变更归纳成一句话作为 PR 描述

处理 Review 意见

/pr fix feedback

自动处理 PR 上的代码审查意见（Review Comments），Copilot 会逐条分析并修改代码。

解决合并冲突

/pr fix conflicts

将当前分支与 base 分支同步并自动解决冲突。

配置默认合并策略，在 ~/.copilot/settings.json 或 .github/copilot/settings.json 中：

{
  "mergeStrategy": "rebase"
}

可选值：rebase（默认）或 merge。

修复 CI 失败

/pr fix ci

自动诊断并修复失败的 CI 检查。可以追加额外指令：

/pr fix ci 重点排查测试失败的原因

一次执行所有修复

/pr fix
# 或
/pr fix all

按顺序依次执行三个修复阶段：

1. Review 意见（feedback）
2. 合并冲突（conflicts）
3. CI 失败（ci）

全自动 PR 工作流

/pr auto

这是最强大的模式：如果当前分支还没有 PR，先创建一个；然后循环执行所有修复流程，直到满足以下所有条件：

• 没有待处理的 Review 意见
• 没有合并冲突
• 所有 CI 检查通过

适合"改完代码就丢给 AI 处理后续"的工作流。

常见问题

Q: /pr fix ci 失败率高，适合什么场景？

A: 适合标准化的 CI 问题（单元测试失败、lint 错误、类型错误），对依赖外部服务或环境差异的 CI 失败效果有限。追加具体描述（如"重点看 test-integration 这个 job"）能提升成功率。

Q: /pr auto 会不会无限循环？

A: 如果某类问题无法自动修复（比如需要人工决策的设计问题），Copilot 会在几轮尝试后停下来，告诉你需要手动介入。

Q: 和 GitHub Web 的 Copilot 有什么区别？

A: /pr 命令是本地 CLI 环境下操作，代码修改在你的本地机器上执行；GitHub Web 上的 Cloud Agent 操作在 GitHub 服务器端进行，适合需要在独立环境执行的任务。