SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场pr-update

pr-update

编程与开发

查看项目

更新于 10-16 07:45

技能介绍

用途

PR Update 是一个把「创建 PR/MR」和「更新 PR/MR」合二为一的技能。它的目标是让 PR/MR 的标题与正文匹配分支当前的实际状态，而不是只反映最新一次提交。当分支尚无 PR/MR 时创建，已存在时则就地编辑标题与描述，不重复开单。

主要能力

  • 检测当前分支是否已有 PR/MR（gh pr view / glab mr view）。没有则创建（必要时用 -u 推送上游）；已存在则就地编辑标题与正文，不创建重复项。
  • 基于 PR 中的全部提交与文件（而非单个提交）起草标题和正文。
  • 更新时先读取现有正文，逐字保留其中的媒体内容，再重写文字部分，使 Summary / Test plan（或仓库惯用章节）保持准确。
  • 在创建或刷新 PR 的过程中整理分支提交：默认按主题拆分（通常 2–5 个），每个提交只关注一件事，并匹配仓库近期提交风格。
  • 最终以 Markdown 链接形式输出 PR/MR，包含编号与完整 forge URL（如 #123，GitLab 用 ! 等价形式），不使用裸 #123。

使用方式

  1. 用 git status / git diff / git log / git diff <default>...HEAD（以及远程跟踪）了解完整变更集，而不只是最新提交。
  2. 检测该分支是否已有 PR/MR。
  3. 起草标题与正文：标题简洁、聚焦「为什么」，在仓库风格明显时与之保持一致；正文优先使用仓库模板，否则采用：
## Summary
<1-3 bullets of what changed and why>

## Test plan
- [ ] <concrete checks>

发布前将文字过一遍 no-tropes。不要擅自添加 reviewer、label 或 milestone，除非被要求。

  1. 应用变更：gh pr create / gh pr edit（或 glab 等价命令）。更新正文时建议从文件读取，避免 shell 吞掉换行或媒体：
# GitHub — read
gh pr view --json url,title,body,baseRefName,headRefName

# GitHub — create
gh pr create --title "…" --body "$(cat <<'EOF'
…
EOF
)"

# GitHub — update (body from file avoids shell-eating newlines/media)
gh pr view --json body -q .body > /tmp/pr-body.md
# …edit /tmp/pr-body.md carefully…
gh pr edit --title "…" --body-file /tmp/pr-body.md

# GitLab
glab mr view
glab mr create
glab mr update <N> --title "…" --description-file /tmp/pr-body.md

提交整理

  • 提交前检查有效的 user.name 与 user.email。GitHub 登录不会设置提交归属；若邮箱未设置或 Git 推断出本地主机地址，应在发布前停止并确认一个与账号关联的邮箱。绝不忽略 Git 的推断身份警告后继续发布。
  • 默认按主题拆分提交（2–5 个较典型），除非用户希望合并为一个。
  • 匹配仓库近期提交风格（git log --oneline -15）；主题行体现「为什么」，不用「WIP」「fix stuff」。
  • 用 soft reset + 按路径暂存的方式重建提交（不用 git rebase -i，因为它需要 TTY）。在 force-push 前展示最终的 git log --oneline <default>..HEAD。
  • 该流程有两个陷阱：soft reset 应指向分支真正的 base SHA（git merge-base HEAD origin/<default>），而不是 origin/<default> 本身，因为它会在任务中途移动，从而把别人的提交当成自己的暂存；git reset <base> -- <path> 会让该路径处于未暂存状态，下一次 git commit 会静默捕获其编辑前版本，因此 force-push 前要验证内容已落地（git show <sha>:<path> | grep <new symbol>）。
  • 重塑他人工作时保留作者归属（Co-authored-by / cherry-pick），尤其在 pr-triage 抢救场景。
  • 不要把纯格式化与逻辑改动混在一起，不要提交 secrets/.env，未经询问不要重写已在默认分支上的提交。

保留媒体（硬性规则）

当 PR/MR 已有正文时，绝不删除媒体。以下内容视为媒体，需逐字保留（尽量保持相同 URL、标记与顺序）：

  • Markdown 图片 / 指向图片或视频的链接（、... 指向媒体）
  • HTML <img>、<video>、<source>、媒体块之间使用的 <br>
  • GitHub/GitLab 上传 / user-attachments / moved-image URL
  • 仅含图片/视频的段落，或包裹媒体的 HTML 注释

更新流程：

  1. 读取现有正文。在使用面向行的文件工具前，先用 jq -r '.description' 把 JSON 描述提取为纯 Markdown；一个很长的转义 JSON 字符串即使整体文件能放下也可能被截断。若内容被截断，应拒绝而不是重建一个不完整的描述。
  2. 提取并保留媒体块。
  3. 重写文字章节，使其匹配当前 diff。
  4. 重新附上保留的媒体（相同块，通常放在末尾，除非原本有意交错，则保持交错）。
  5. 提交前对比新旧正文：旧正文中的每个媒体 URL/标记都必须仍然存在。
  6. 如果刷新会导致媒体丢失，应停止并保留旧正文（或只改标题），而不是发布一个被剥离媒体的描述。

适用场景

  • 分支已有新提交，需要让 PR 标题与描述重新匹配当前 diff。
  • 分支尚无 PR/MR，需要创建并整理提交历史。
  • 需要在更新描述时保留已有的截图、录屏等媒体内容。

限制与范围

  • 范围内：打开 PR/MR、创建时按需推送、整理提交、改标题、重写描述、保留媒体、打印 URL。
  • 范围外：rebase、CI、评审线程（pr-ready）、triage/salvage（pr-triage）、合并。
  • 不擅自添加 reviewer、label 或 milestone。
  • 不提交 secrets/.env，不未经询问重写默认分支上的提交。
  • 关于收费、价格、平台支持范围等更多信息，资料中暂未提供。