Commit 信息生成

Q: Conventional Commits 的格式到底长什么样？

v1.0.0 定义为：<type>[optional scope][optional !]: <description>，可选地跟一个空行加 body，再可选地跟一个空行加若干 footer。type 必须是名词（feat、fix 等），description 必须紧跟在冒号与空格之后。示例：fix(parser): handle empty input。

Q: 破坏性变更该怎么标记，两种写法有区别吗？

两种等价写法：① 在 type / scope 后、冒号前加 !（feat(api)!: remove legacy field）；② 在页脚写 BREAKING CHANGE: 说明。规范里两者含义相同，都表示不兼容变更并对应 major 版本。实践中推荐两个都写：! 让列表视图一眼看到，页脚则说明迁移方式。

Q: 为什么 feat 升 minor、fix 升 patch？

这是 Conventional Commits 明确写进规范的 SemVer 映射：fix 类提交对应 PATCH（向后兼容的缺陷修复），feat 类提交对应 MINOR（向后兼容的新功能），任何带 BREAKING CHANGE 的提交对应 MAJOR（不兼容变更）。规范只定义了这三条，其他 type 的版本影响由团队自行约定，本工具给出的属于社区惯例参考。

Q: type 可以自己定义吗？

可以。规范要求 type 是名词即可，feat / fix 之外的类型（如 docs、chore）都来自社区约定而非规范本身。关键是团队内统一：建议把可选 type 写进 CONTRIBUTING，并用 commitlint 在 CI 里强制校验。本工具内置的 11 类是目前最通行的集合，不在列表内时会给出提示但不会判为错误。

Q: 为什么要求描述小写开头、结尾不加句号？

这两条不是规范强制项，而是社区长期形成的书写惯例（源自 Git 自身的提交风格）：小写开头让 git log 列表更整齐，结尾不加标点避免多余字符。本工具把它们标为「⚠️ 可优化」而非「❌ 不合规」，不影响是否通过校验。

Q: scope 和 body 都必须写吗？

都不是必须的。scope 用来说明改动落在代码库的哪个部分（如 parser、api），不确定时留空完全合规；body 用来解释「为什么这么改」，一句描述能说清时也可以省略。但要注意：一旦写了 body 或 footer，前面必须有空行，否则会被解析成同一段。

Q: 粘贴的提交信息会被上传吗？

不会。解析、校验与生成全部在你的浏览器内完成，没有任何网络请求。仅会记住你上次选择的类型与输入内容（保存在本机 localStorage），方便下次继续使用。

Q: 多段 git commit -m 命令怎么用？

带正文或页脚时，可用多个 -m 让 Git 把每段当作独立段落，段落之间自动插入空行：git commit -m "feat: xxx" -m "正文说明" -m "Refs: #1288"。点「📋 复制 git 命令」即可拿到拼好的命令。更省事的写法是直接把完整信息写进编辑器（git commit 不带 -m），结构更直观。

工程规范完全免费 📐 规范 v1.0.0 🔢 SemVer 影响 🔒 本地处理不上传 🌙 支持黑夜模式

提交信息写得太随意，CHANGELOG 生成不了、版本号靠拍脑袋？按 Conventional Commits 选好 type、scope 与破坏性标记，这里帮你拼出规范提交信息并算出对应的 SemVer 版本影响；已有提交也能粘进来逐项体检。

类别程序员 · 工程规范

运行方式纯前端 · 本地处理

规范版本Conventional Commits v1.0.0

版本映射SemVer（semver.org）

📝 提交信息生成 / 校验

Conventional Commits v1.0.0 · 含 SemVer 版本影响

按 <type>[scope][!]: <description> 结构生成规范的提交信息，或粘贴已有提交信息逐项体检。全部在本地处理，不上传任何内容。

类型 type

范围 scope（可选）

描述 description

这是破坏性变更（不兼容的 API 变化），加 ! 并自动补 BREAKING CHANGE: 页脚

正文 body（可选）

页脚 footer（可选）

🚀 快捷选类型

📄 生成的提交信息

核心特性

按规范拼装 type / scope / ! / description

11 类常用 type 一键选择

破坏性变更自动加 ! 与 BREAKING CHANGE 页脚

正文与页脚分段拼装

实时预览生成的提交信息

一键复制提交信息与 git commit 命令

SemVer 版本影响（major / minor / patch）

粘贴已有提交信息解析结构

首行结构、大小写、长度、空行逐项体检

给出修正后的规范写法

提交信息为什么要写成一种「格式」？

随手写的 update、fix bug、改了点东西，人看着还行，机器却完全读不懂。而一旦提交信息有固定结构，就能自动做事：扫描 feat / fix 自动生成 CHANGELOG、根据 BREAKING CHANGE 自动决定版本号该不该跳 major、按 scope 统计哪些模块改动最频繁、在 CI 里拦截不合规的提交。

Conventional Commits 就是目前最通行的这套结构，v1.0.0 的定义很简洁：

<type>[optional scope][optional !]: <description>
[optional body]
[optional footer(s)]

关键点：type 是名词（feat、fix…），scope 用括号紧跟 type，! 表示破坏性变更（也可用页脚 BREAKING CHANGE:），描述紧跟冒号后的空格；正文与页脚各自前要有空行。它和 SemVer 的对应关系也是规范明确写死的：fix → PATCH、feat → MINOR、BREAKING CHANGE → MAJOR。

本工具做两件事：生成——按规范拼出提交信息并告诉你这次改动会推动哪个版本号；校验——把已有提交信息拆成 type / scope / 描述 / 正文 / 页脚，逐项检查是否合规。所有处理都在浏览器本地完成，不上传任何内容。规范只明确了上述三种版本映射，perf、refactor 等其他类型的版本影响属于社区惯例，本工具给出的是参考值，请以你团队的发布流程为准。

怎么用

选择 type

在下拉或「快捷选类型」里点选本次改动的性质：加功能用 feat、修 bug 用 fix、改文档用 docs……
填写 scope 与描述

scope 填受影响的模块（如 auth、parser），描述用小写开头、不加句号的祈使句，如 add sso login entry。
标记破坏性变更

若这次改动不兼容旧行为，勾选「破坏性变更」，会自动加 ! 并补上 BREAKING CHANGE: 页脚。
补充正文与页脚

正文写「为什么改」与行为差异，页脚写关联 Issue（Refs: #1288）或审阅人（Reviewed-by: Alice）。
复制使用

点「📋 复制提交信息」直接粘贴到提交框，或点「📋 复制 git 命令」拿走带多段 -m 的终端命令。
校验已有提交

切到「🔍 校验已有提交」，粘贴一段提交信息，即可看到解析结果与逐项体检结论。

使用技巧

type 用名词、描述用祈使句：feat: add export button 而不是 feat: added export button。
描述结尾不加句号，且建议控制在 72 字符内——GitHub 在列表视图里会截断更长的首行。
scope 里别加空格：多个单词用短横线，如 user-profile；不确定就留空，scope 是可选的。
正文和页脚前必须有空行，这是规范里最容易被忽略的一条，没有空行会被当成同一段。
! 与页脚 BREAKING CHANGE: 等价，二选一即可；两者都出现也没问题。规范里该 token 为大写，本工具做了大小写宽容处理。
页脚 token 里的空格要写成短横线：Acked-by 而不是 Acked by；BREAKING CHANGE 是唯一例外。
一次提交只做一件事：又要加功能又要重构，应拆成 feat 与 refactor 两个提交，否则版本号该怎么升会变得含糊。
revert 类型建议写清被回滚的提交：revert: feat(auth): add sso login entry，并在正文说明原因。
版本映射只有 fix → patch、feat → minor、BREAKING → major 是规范定义的；docs、test、chore 等通常不触发发布，本工具的这类结论是社区惯例参考。
想强制落地，可在 CI 里接 commitlint，与本工具使用同一套规则。

更新记录

v1.0 2026-09-20 首次上线：Conventional Commits v1.0.0 提交信息生成（type / scope / ! / 描述 / 正文 / 页脚）、SemVer 版本影响判断、提交信息与 git 命令一键复制，以及已有提交信息的结构解析与逐项体检。

常见问题

Conventional Commits 的格式到底长什么样？

v1.0.0 定义为：<type>[optional scope][optional !]: <description>，可选地跟一个空行加 body，再可选地跟一个空行加若干 footer。type 必须是名词（feat、fix 等），description 必须紧跟在冒号与空格之后。示例：fix(parser): handle empty input。

破坏性变更该怎么标记，两种写法有区别吗？

两种等价写法：① 在 type / scope 后、冒号前加 !（feat(api)!: remove legacy field）；② 在页脚写 BREAKING CHANGE: 说明。规范里两者含义相同，都表示不兼容变更并对应 major 版本。实践中推荐两个都写：! 让列表视图一眼看到，页脚则说明迁移方式。

为什么 feat 升 minor、fix 升 patch？

这是 Conventional Commits 明确写进规范的 SemVer 映射：fix 类提交对应 PATCH（向后兼容的缺陷修复），feat 类提交对应 MINOR（向后兼容的新功能），任何带 BREAKING CHANGE 的提交对应 MAJOR（不兼容变更）。规范只定义了这三条，其他 type 的版本影响由团队自行约定，本工具给出的属于社区惯例参考。

type 可以自己定义吗？

可以。规范要求 type 是名词即可，feat / fix 之外的类型（如 docs、chore）都来自社区约定而非规范本身。关键是团队内统一：建议把可选 type 写进 CONTRIBUTING，并用 commitlint 在 CI 里强制校验。本工具内置的 11 类是目前最通行的集合，不在列表内时会给出提示但不会判为错误。

为什么要求描述小写开头、结尾不加句号？

这两条不是规范强制项，而是社区长期形成的书写惯例（源自 Git 自身的提交风格）：小写开头让 git log 列表更整齐，结尾不加标点避免多余字符。本工具把它们标为「⚠️ 可优化」而非「❌ 不合规」，不影响是否通过校验。

scope 和 body 都必须写吗？

都不是必须的。scope 用来说明改动落在代码库的哪个部分（如 parser、api），不确定时留空完全合规；body 用来解释「为什么这么改」，一句描述能说清时也可以省略。但要注意：一旦写了 body 或 footer，前面必须有空行，否则会被解析成同一段。

粘贴的提交信息会被上传吗？

不会。解析、校验与生成全部在你的浏览器内完成，没有任何网络请求。仅会记住你上次选择的类型与输入内容（保存在本机 localStorage），方便下次继续使用。

多段 git commit -m 命令怎么用？

带正文或页脚时，可用多个 -m 让 Git 把每段当作独立段落，段落之间自动插入空行：git commit -m "feat: xxx" -m "正文说明" -m "Refs: #1288"。点「📋 复制 git 命令」即可拿到拼好的命令。更省事的写法是直接把完整信息写进编辑器（git commit 不带 -m），结构更直观。

💬 留言板 0

全部留言需审核通过后展示

💬

还没有留言，来抢沙发吧！