Back to Details

release-tag

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Release Tag

发布标签

Create a signed git release tag and push it. The workflow is interactive — the user confirms every step before anything is pushed.
创建带签名的git发布标签并推送。该工作流是交互式的——所有内容推送前，每一步操作都会经过用户确认。

Workflow

工作流程

1. Ensure the default branch is current

1. 确保默认分支为最新版本

Detect the default branch — don't assume 
main
:
bash
git remote show origin | sed -n '/HEAD branch/s/.*: //p'
Then checkout and pull:
bash
git checkout <default-branch> && git pull origin <default-branch>
If the working tree has uncommitted changes, stop and tell the user. Don't stash or discard anything — let them decide.
检测默认分支——不要默认假设是
main
：
bash
git remote show origin | sed -n '/HEAD branch/s/.*: //p'
然后检出并拉取最新代码：
bash
git checkout <default-branch> && git pull origin <default-branch>
如果工作树存在未提交的变更，停止操作并告知用户。不要暂存或丢弃任何内容——让用户自行决定处理方式。

2. Find the latest tag

2. 查找最新标签

bash
git describe --tags --abbrev=0
Parse the version components (e.g., 
v1.21.3
→ major=1, minor=21, patch=3). If no tags exist, start from 
v0.1.0
.
bash
git describe --tags --abbrev=0
解析版本号各组成部分（例如
v1.21.3
→ 主版本=1，次版本=21，修订版本=3）。如果不存在任何标签，从
v0.1.0
开始。

3. Determine the next version

3. 确定下一个版本号

Look at commits since the last tag to decide whether this is a minor or patch bump:
bash
git log <latest-tag>..HEAD --oneline
Patch bump (v1.21.3 → v1.21.4): Only bug fixes, docs, chores, refactors, dependency bumps, or minor tweaks. Look for commit prefixes like 
fix
, 
chore
, 
docs
, 
refactor
, 
perf
, 
style
, 
ci
, 
build
.
Minor bump (v1.21.3 → v1.22.0): Any new features or meaningful behavior changes. Look for commit prefixes like 
feat
, or commits that clearly add new functionality even without conventional commit prefixes.
Never bump major. If commits look like breaking changes, still suggest a minor bump and note the breaking changes to the user.
When in doubt, default to patch.
查看上一个标签之后的提交记录，判断本次是次版本升级还是修订版本升级：
bash
git log <latest-tag>..HEAD --oneline
修订版本升级（v1.21.3 → v1.21.4）：仅包含Bug修复、文档更新、日常维护、重构、依赖升级、微小调整。查找带有
fix
、
chore
、
docs
、
refactor
、
perf
、
style
、
ci
、
build
等前缀的提交。
次版本升级（v1.21.3 → v1.22.0）：包含任何新功能或有意义的行为变更。查找带有
feat
前缀的提交，或是即使没有符合约定式提交前缀、但明显新增了功能的提交。
永远不要自动升级主版本。如果提交看起来包含破坏性变更，仍然建议升级次版本，并向用户说明存在破坏性变更。
存在疑问时，默认选择修订版本升级。

4. Present the plan and ask for confirmation

4. 展示方案并请求确认

Show the user:
  • Current latest tag
  • The commits since that tag (short log)
  • Your recommended version and why (minor vs patch)
  • The exact commands that will run
Use AskUserQuestion to let them confirm or pick a different version. Offer both the minor and patch options so they can override your recommendation.
向用户展示：
  • 当前最新标签
  • 该标签之后的提交记录（精简日志）
  • 你推荐的版本号及理由（次版本/修订版本升级）
  • 即将执行的具体命令
使用AskUserQuestion让用户确认，或者选择其他版本号。同时提供次版本和修订版本升级两个选项，方便用户覆盖你的推荐方案。

5. Create and push the tag

5. 创建并推送标签

Only after the user confirms:
bash
git tag -s v<VERSION> -m "v<VERSION>"
git push origin v<VERSION>
Use 
git push origin v<VERSION>
(pushing the specific tag) rather than 
git push --tags
to avoid accidentally pushing other local tags.
仅在用户确认后执行：
bash
git tag -s v<VERSION> -m "v<VERSION>"
git push origin v<VERSION>
使用
git push origin v<VERSION>
（推送指定标签）而非
git push --tags
，避免意外推送其他本地标签。

6. Confirm success

6. 确认操作成功

Show the tag that was created and a link to the releases page if it's a GitHub repo (check with 
git remote get-url origin
).
展示已创建的标签，如果是GitHub仓库，同时提供发布页面的链接（可通过
git remote get-url origin
检测）。