01
每行粘贴一条提交 header
按 `git log --pretty=format:%s` 的输出格式粘贴,每行一条 `type(scope)!: subject`。这里不解析带正文或 `BREAKING CHANGE:` 脚注的完整多行提交消息;破坏性变更请改用 type 或 scope 后面的 `!` 标记。
- 先加载任意一个示例,看清楚 header 的写法再粘贴自己的提交。
CI/CD 工具
语义化发布助手从提交记录推算版本、CHANGELOG 与构建号
粘贴提交记录、填入当前版本号,即可获得版本建议、CHANGELOG 草稿与构建号。
语义化发布助手
提交记录(每行一条 header)
提交记录和版本号均在浏览器本地解析,不会上传,也不会调用任何 Git 或 CI 服务。
结果
粘贴提交记录或填写版本号即可开始。
选项
无法识别的行不会阻断计算;这个选项只决定它们是否出现在 CHANGELOG 草稿的“其他”分组里。
粘贴提交记录或填写版本号即可开始。
打标签发布之前,你通常要手动回答三个问题:下一个版本号是多少、CHANGELOG 里写什么、这次发布用哪个构建号。这个语义化发布助手用同一批提交记录一次性回答这三件事,让版本号、CHANGELOG 和构建号字符串不会各说各话。
它和自己手动升版本号、把条目抄进 CHANGELOG.md 不一样:每一条版本号建议都来自对提交 header 的解析,规则与我们的 Conventional Commit 生成器完全一致,不是靠猜 diff 或调用 AI。你粘贴的内容不会离开浏览器,工具也不会创建标签、推送代码,或调用任何 Git / CI API——它只生成文本,交给你自己使用。
为什么用这个语义化发布助手
看看版本号、CHANGELOG 和构建号都来自同一批提交时会有什么不同。
确定性建议,不靠 AI 猜测
有些发布计算器让你用自由文本描述改动,再发给 AI 猜一个版本号。这个语义化发布助手改用和我们的 Conventional Commit 生成器完全一致的语法逐行解析提交 header——同样的输入永远得到同样的建议,而且全程不发出任何网络请求。
版本号、CHANGELOG 与构建号共用同一个版本
单独的版本计算器、CHANGELOG 生成器和构建号生成器互相不知道对方的结果。这里,推算出的版本号会直接用在 CHANGELOG 标题里,也会填进构建号模板的 {version} 占位符,三者始终保持一致。
发布前一键跳转 ENV diff
生成结果后,结果区会直接链接到我们的 ENV diff 工具,方便你在部署前比对环境变量——这是我们对比过的独立 CHANGELOG、构建号生成器都没做的一步。
第一次用容易踩的三个点
粘贴第一批提交记录之前,先弄清楚这三件事。
02
填写当前版本号并调整构建号模板
填入严格 semver 格式的当前版本号(例如 1.4.2),需要时再调整构建号模板。默认模板 `{version}+{yyyyMMdd}.{count}` 会用上建议版本号、今天的日期,以及你自己填写的构建计数——工具没有 CI 上下文,读不到真实的构建序号。
关闭自动生成可以先改完多个字段再统一计算,按 Ctrl/Cmd+Enter 手动运行一次。
03
看懂变化徽章,再导出结果
徽章(大版本、小版本、补丁版本或无变化)显示的是哪类提交把版本级别拉高了——破坏性标记始终压过普通的 feat 或 fix。打标签前,复制或下载 CHANGELOG、复制构建号,或者点击跳转到 ENV diff。
任何输入变化都会让上一次结果变灰,复制和下载会被禁用,直到重新生成。
查看哪些内容不会被解析这个计算器用你的提交记录做了什么
四个环节,把一批提交 header 变成可以直接使用的发布草稿。
只解析单行 Conventional Commit header
本语义化发布助手按 `type(scope)!: subject` 的语法解析每一行,规则与我们的 Conventional Commit 生成器一致;逐行判定影响级别后取整批里最高的一个——只要有一行带 `!` 或者是 `feat`,整个发布就会被拉高。
从提交记录生成更新日志,破坏性变更置顶
被识别的提交按 Breaking Changes、Features、Fixes、Other 四组分类,渲染成 Keep a Changelog 风格的 Markdown,可以直接复制、下载为 CHANGELOG.md,或贴进你自己的发布说明——破坏性条目永远排在最前面。
构建号模板可以自己定
用 `{version}`、`{yyyy}`、`{yyyyMM}`、`{yyyyMMdd}` 和手动填写的 `{count}` 拼出你的 CI 需要的任意构建号格式;模板里出现未知占位符时会原样保留并提示,不会被悄悄丢弃。
无法识别的行不会卡住结果
不符合提交 header 语法的行会被跳过、不参与版本计算,但会单独计数,不会中断整体计算——关闭“忽略”选项还能在 CHANGELOG 的 Other 分组里看到它。
这个工具会解析什么,不会解析什么
粘贴真实发布的提交记录之前,值得先了解的边界情况。
- 只读取单行提交 header
- 带正文或 `BREAKING CHANGE:` 脚注的完整多行提交消息不受支持——多条消息按行拼接后,空行分隔的脚注边界没法和下一条提交的 header 可靠区分开。破坏性变更请改用 `!` 标记。
- 单次最多 1,000 行或 100,000 字符
- 超出这个上限会直接报错,而不是悄悄截断你的提交记录——很大的发布窗口请拆成更小的批次分别处理。
- 当前版本号必须是严格的 semver 字符串
- 像 `v1.4.2`、`1.4` 或带前导零的版本号都会被拒绝并定位到该输入;在填成 `1.4.2` 这种形式之前,建议区会保持空白。
- 不会发布、不会打标签,也不读取 CI
- 工具不会从仓库拉取提交,不会创建标签,`{count}` 也永远不会从真实的构建序号读取——它只是把粘贴的文本转换成版本号、CHANGELOG 草稿和构建号字符串,交给你在别处使用。
语义化发布助手常见问题
关于用提交记录推算版本号,大家实际会问的问题。
有什么自动生成 CHANGELOG 的好方式吗?
把提交记录按每行一条 header 粘贴进来,这个语义化发布助手会按 feat、fix、breaking 自动分组,生成 Keep a Changelog 风格的草稿,可以直接复制或下载成 CHANGELOG.md,不需要手动誊抄。
APP 发布版本如何生成构建号?
在选项里编辑构建号模板。默认的 `{version}+{yyyyMMdd}.{count}` 会用上建议出的版本号、今天的日期,以及你自己填写的构建计数——工具没有 CI 运行环境,读不到应用商店或 CI 里的真实构建号,所以 `{count}` 需要手动填写。
commit 不写规范会有什么后果?
不符合 `type(scope)!: subject` 语法的那一行会被标记为“无法识别”:它不参与版本建议的计算,只会被单独计数;默认情况下也不会出现在 CHANGELOG 草稿里,除非关闭“忽略无法识别的行”这个选项。
fix 和 feat 到底该怎么写?
两者都写在 header 里:`fix(scope): 描述` 只会触发补丁版本,`feat(scope): 描述` 会触发小版本。如果这次改动不兼容旧版本,在 type 或 scope 后面加一个 `!`(例如 `feat(auth)!: …`),就会触发大版本——这也是本工具目前识别破坏性变更的唯一方式。
带 BREAKING CHANGE 脚注的提交为什么会让版本号跳大版本?
在完整的 Conventional Commits 规范里,消息正文里的 `BREAKING CHANGE:` 脚注确实等同于破坏性变更。但本工具目前只解析单行提交 header,不解析多行正文和脚注,所以这里必须改用 `!` 标记(写在 type 或 scope 后面)才能触发大版本跳跃,单靠 `BREAKING CHANGE:` 脚注在这里不会生效。
没找到你要的答案?
现在就用语义化发布助手
把提交记录粘贴进这个语义化发布助手,确认当前版本号,几秒内就能拿到版本建议、CHANGELOG 草稿和构建号。
全部处理都在浏览器本地完成——不需要注册、不会上传数据,也不会替你创建标签或触发部署。
全部解析都在浏览器本地完成,不会替你打标签或发布。