| name | git-release |
| description | 自动化 GitHub/GitLab/Gitea 发布流程。使用场景：发布新版本、创建版本标签、更新 CHANGELOG。自动分析 Git 提交、更新 CHANGELOG.md、确定语义化版本号、创建 Git 标签、推送到远程并创建 Release |
Git 自动发布（GitHub / GitLab / Gitea）
自动化 GitHub/GitLab/Gitea Release 发布流程，遵循语义化版本（Semantic Versioning）规范。自动分析 Git 提交记录并更新 CHANGELOG.md，然后确定合适的版本号并完成发布。
发布流程
步骤 0: 确认 Git 平台
如果对话中已通过任意 git 技能确定过平台信息（平台 + owner/repo），直接复用，跳过本步骤。
首次检测时执行：
git remote get-url origin
解析 URL 判断平台：
- GitHub:
github.com 域名 → 提取 owner/repo
- GitLab:
gitlab.com 或自托管域名 → 提取 owner/repo
- 其他域名: 尝试调用
<域名>/api/v1/version 检测是否为 Gitea 实例
- 成功识别 → 作为 Gitea 处理，提取
owner/repo
- 检测失败 → 提示用户手动选择平台（GitHub/GitLab/Gitea/其他），或询问是否仅执行 git tag/push
检测完成后记住平台信息，供后续 git 技能复用。
步骤 1: 准备发布数据
收集并计算所有发布所需信息，不执行任何写操作。
1.1 获取自上次发布以来的提交
先获取最新 tag：
git describe --tags --abbrev=0 2>/dev/null
有 tag 时查看后续提交：
git log v1.2.3..HEAD --pretty=format:"%h %s" --reverse
无 tag 时查看全部提交：
git log --pretty=format:"%h %s" --reverse
对包含 ! 后缀的提交或需要检查 body 的提交，单独获取完整信息：
git log <hash> -1 --pretty=format:"%B"
1.2 解析并分类提交信息
| 类型 | CHANGELOG 分类 | 说明 |
|---|
feat / feature | Added | 新功能 |
fix / bugfix | Fixed | Bug 修复 |
! 后缀 / BREAKING CHANGE footer | Changed | 破坏性变更 |
以下类型默认不进入 CHANGELOG：refactor、perf、chore、docs、test、style。如果某个提交确实值得记录（如重大性能优化），可酌情归入 Changed。
破坏性变更检测：
- 类型后加
!：feat!: 移除旧 API 或 feat(api)!: 移除旧端点
- Footer 中声明：
BREAKING CHANGE: v1 端点不再可用
Scope 处理：提交格式 type(scope): description → CHANGELOG/Release Notes 中显示为 scope: description
1.3 确定版本号
- 存在破坏性变更 → MAJOR (X.0.0)
- 有
feat 类提交（无破坏性） → MINOR (x.Y.0)
- 仅有
fix 类提交 → PATCH (x.y.Z)
确定版本号后先与用户确认：
当前版本：1.2.3
分析了 X 个提交（自 v1.2.3 以来）：
- 3 个 Added（新功能）
- 1 个 Changed（包括 1 个破坏性变更）
- 1 个 Fixed（Bug 修复）
推荐版本：v2.0.0（检测到破坏性变更）
确认版本号？(y/输入其他版本号)
用户确认版本号后才继续生成 CHANGELOG 和 Release Notes。
1.4 生成 CHANGELOG 内容
基于分类结果，准备 CHANGELOG.md 的变更内容（在内存中生成，不写入文件）。
条目格式：
- scope 显示为
scope: 格式：- api: 添加新接口
- 无 scope 直接写描述：
- 新功能描述
- 破坏性变更添加前缀：
- **Breaking**: 变更说明
1.5 生成 Release Notes
## What's Changed
### Added
- scope: 新功能描述
### Fixed
- scope: Bug 修复描述
### Changed
- **Breaking**: 破坏性变更说明
**Full Changelog**: https://github.com/owner/repo/compare/vA.B.C...vX.Y.Z
格式要求：
- 标题固定使用
## What's Changed（英文，保持历史版本一致性）
- 分类：
### Added（新功能）、### Fixed（Bug 修复）、### Changed（其他变更）
- 空分类省略，不要输出空的分类标题
- GitLab 链接使用
/-/compare/ 路径格式，Gitea 链接使用 /compare/ 路径格式（同 GitHub）
步骤 2: 预览确认
将所有发布数据一次性展示给用户：
📦 发布预览
版本：v2.0.0（当前 v1.2.3）
提交：分析了 X 个提交（自 v1.2.3 以来）
--- CHANGELOG 变更 ---
（展示将写入 CHANGELOG.md 的完整 diff）
--- Release Notes ---
（展示完整的 Release Notes）
确认发布？可修改版本号、CHANGELOG 内容或 Release Notes。(y/n)
用户可要求修改任何部分，修改后重新预览，再次确认。用户明确确认后才进入步骤 3。
步骤 3: 执行发布
用户确认后，按顺序执行以下操作：
3.1 更新 CHANGELOG.md
- 将
## [Unreleased] 替换为 ## [X.Y.Z] - YYYY-MM-DD
- 在
## [X.Y.Z] 上方插入新的空 ## [Unreleased]（保持 Keep a Changelog 规范）
- 在文件底部添加版本比较链接：
GitHub：
[X.Y.Z]: https://github.com/owner/repo/compare/vA.B.C...vX.Y.Z
[Unreleased]: https://github.com/owner/repo/compare/vX.Y.Z...HEAD
GitLab：
[X.Y.Z]: https://gitlab.com/owner/repo/-/compare/vA.B.C...vX.Y.Z
[Unreleased]: https://gitlab.com/owner/repo/-/compare/vX.Y.Z...HEAD
Gitea：
[X.Y.Z]: https://gitea.example.com/owner/repo/compare/vA.B.C...vX.Y.Z
[Unreleased]: https://gitea.example.com/owner/repo/compare/vX.Y.Z...HEAD
3.2 提交 CHANGELOG
git add CHANGELOG.md
git commit -m "chore: release vX.Y.Z"
3.3 创建并推送标签
git tag -a vX.Y.Z -m "Release vX.Y.Z"
获取当前分支名后推送：
git branch --show-current
git push origin <branch>
git push origin vX.Y.Z
3.4 创建 Release
GitHub：
gh release create vX.Y.Z \
--title "vX.Y.Z" \
--notes "$(cat <<'EOF'
...（格式化的 Release Notes）
EOF
)"
GitLab：
glab release create vX.Y.Z \
--name "vX.Y.Z" \
--notes "$(cat <<'EOF'
...（格式化的 Release Notes）
EOF
)"
自托管 GitLab 需先配置：glab config set host gitlab.example.com
Gitea：
tea releases create \
--tag vX.Y.Z \
--title "vX.Y.Z" \
--note "$(cat <<'EOF'
...（格式化的 Release Notes）
EOF
)"
自托管 Gitea 需先配置：tea login add --url=https://gitea.example.com --token=...
认证失败时：提供 Web UI 手动创建发布的链接，以及格式化的发布说明供复制粘贴。
错误处理
| 场景 | 处理 |
|---|
| 不支持的 Git 平台 | 通知用户，询问是否仅执行 git tag/push |
| 没有未发布变更 | 通知用户并询问是否继续 |
| Git 工作区不干净 | 中止并要求用户先提交/暂存变更 |
| 认证失败（gh/glab/tea） | 提供 Web UI 备选方案和格式化内容 |
| 推送冲突 | 指示用户先 pull/rebase 再重试 |
| 未配置远程仓库 | 中止并要求用户先配置 |
注意事项
- 确保所有要发布的更改已提交
- CHANGELOG.md 应存在于仓库根目录
- 提交消息建议使用 Conventional Commits 格式以便自动分类
