打 patch/minor/major…

当需要为仓库切 patch、minor 或 major 发布时，先同步远端默认分支并读取既有发布惯例，再计算版本、验证目标、按既有类型打标签、推送并观察发布到绿色。

适用场景

解决思路

1. 在仓库既定版本格式和标签类型下，给 origin 默认分支 HEAD 打标签；检查发布惯例、计算下一个版本、验证确切目标、推送标签并观察发布到绿色。
2. 先同步到 origin 默认分支：标签必须指向远端实际存在的提交，而不是本地检出当前所处的位置。
3. 运行 `git remote get-url origin` 获取 origin URL。
4. 运行 `git ls-remote --symref origin HEAD` 查看远端符号 HEAD。
5. 运行 `git fetch origin --tags --prune` 获取标签并清理远端已删除标签。
6. 从 origin URL 解析出 GitHub `owner/repository`；在每个 `gh` 命令中显式传入 `--repo` 或 `-R`，避免 `GH_REPO`、其他 remote 或配置的默认值重定向发布操作。
7. 从远端符号 `HEAD` 解析默认分支，不要用本地分支或可能过期的 `origin/HEAD`；记录其完整 ref 名。
8. 保持工作树和本地分支不变；脏的或分叉的检出不会影响直接从已 fetch 的远端跟踪 ref 创建标签。
9. 记录 `git rev-parse origin/<default-branch>` 作为候选发布提交。
10. 不要在默认分支为红色（CI 未通过）时切发布；如果仓库用 CI 门禁发布，确认该确切提交的检查为绿色。
11. 不要发明版本格式；查看仓库已有发布惯例。
12. 如果发布是 forge Release 对象，运行 `gh release list -R <owner/repository>`；运行 `git ls-remote --tags --refs origin 'refs/tags/<relevant-prefix>*'`。
13. 选择相关包或发布命名空间后再选最新版本；仓库可能包含无关产品标签、包标签或旧格式，它们排序可能在被发布系列之前。
14. 以远端标签 ref 为准；即使运行过 `git fetch --tags --prune`，本地标签仍可能过期或只存在于本地。
15. 先确定相关远端标签系列，再 fetch 并检查匹配的标签对象。
16. 从最新发布读取版本格式：前导 `v` 有无、任何组件或包前缀（monorepo 可能打 `pkg-name/v1.2.3`）、任何预发布或构建后缀。
17. 从最新发布读取标签类型：轻量、附注或签名；用 `git cat-file -t <tag>` 检查（`tag` 对象表示附注/签名，`commit` 表示轻量），并用 `git verify-tag <tag>` 检查签名。
18. 从最新发布读取发布机制：是只推送标签由流水线接管，还是用 `gh release create` 显式创建 forge Release。
19. 如果没有任何先前发布，则没有可 bump 的版本：使用仓库文档化的起始版本，或询问使用哪个版本。
20. 从相关系列的最新标签计算语义化 bump，并保留其前导 `v` 和任何包前缀：patch 为 `x.y.(z+1)`。
21. minor 为 `x.(y+1).0`。
22. major 为 `(x+1).0.0`。
23. 遵循仓库既有的预发布到稳定版转换规则；如果历史不能确定应推进、保留还是去掉预发布后缀，询问用户。
24. 记录计算出的 tag、候选提交 SHA、标签类型和发布机制。
25. 打标签前立即重新 fetch 并确认没有变动：运行 `git ls-remote --symref origin HEAD`。
26. 运行 `git fetch origin --tags --prune`。
27. 运行 `git rev-parse origin/<default-branch>`。
28. 运行 `git ls-remote --tags --refs origin 'refs/tags/<relevant-prefix>*'`。
29. 运行 `gh api 'repos/<owner>/<repository>/commits/<release-sha>/check-runs'`。
30. 运行 `gh api 'repos/<owner>/<repository>/commits/<release-sha>/status'`。
31. 确认默认分支、其 SHA 和最新相关标签未变，拟用标签尚不存在，且发布 SHA 上的必需检查为绿色。
32. 如果任何内容发生变动，重新计算发布并重复此检查。
33. 用现有 CI watcher 等待待处理检查，然后重新检查目标。
34. 对失败的检查进行诊断，并仅在授权范围内修复；必需检查未解决时不要打标签；如果修复需要新授权或没有访问权限，继续独立准备并报告阻塞。
35. 然后显式对已 fetch 的远端 HEAD 打标签，并匹配先前标签的类型。轻量标签：`git tag <version> origin/<default-branch>`。
36. 附注标签：`git tag -a <version> origin/<default-branch> -m "<version>"`。
37. 全局 `tag.gpgsign = true` 会静默把轻量或附注标签变成签名标签；如果仓库现有标签未签名，传入 `--no-sign` 使新标签匹配；如果它们已签名，则签名。
38. 推送标签：`git push origin <version>`。
39. 如果惯例包含 forge release，只在推送已验证的本地标签后创建；使用 `gh release create <version> --verify-tag ...`，匹配先前发布的标题、说明和资产，并传入 `--repo <owner/repository>`。
40. 然后验证结果：运行 `git ls-remote origin 'refs/tags/<version>' 'refs/tags/<version>^{}'`。
41. 运行 `gh run watch <run-id> -R <owner/repository> --exit-status --interval 20`。
42. 运行 `gh release view <version> -R <owner/repository>`。
43. 对于附注或签名标签，将 peeled `^{}` 结果与发布提交 SHA 比较；对于轻量标签，比较直接标签结果。
44. 直到远端标签解析到发布提交、发布流水线为绿色且预期发布产物存在，才算完成。
45. 报告：说明切出的版本、它指向的提交 SHA、标签方式（轻量/附注/签名）以及发布或流水线结果。

适用边界 · 注意事项

• 仓库状态使发布含义不明确，或必需值无法从远端标签、文档或历史推导时，先询问，不要执行。
• 默认分支或候选发布提交的必需 CI 检查不是绿色（含待处理或失败）时，不要打标签。
• 没有先前发布且仓库未记录起始版本，或预发布到稳定版的转换规则无法确定时，不要自行决定。