约定式提交消息格式化工具
根据类型、范围和描述构建符合规范的约定式提交(Conventional Commits)消息，或粘贴现有提交消息将其解析为各个部分。跟踪 72 字符的主题行限制，并自动添加 BREAKING CHANGE 页脚。
输入
该变更涉及代码库的可选区域。
使用祈使语态的简短摘要，末尾不带句号。
输出
| 检查项 | 结果 |
|---|---|
| No data yet | |
使用此工具的更多方式
REST API
curl -X POST https://api.iotools.cloud/v1/tool/conventional-commit-message-formatter \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"mode": "build",
"type": "feat",
"scope": "auth",
"description": "add OAuth2 login support",
"breaking": "true",
"breakingDescription": "The login() function now requires an options obj…",
"body": "Implements the OAuth2 authorization code flow us…",
"footers": "Refs: #482"
}'替换成您账户中的密钥。工具的字段即为请求体——没有额外包装。
让 AI 代理执行
Use the IOTools `conventional-commit-message-formatter` tool (Conventional Commit Message Formatter) on this input:
YOUR_INPUT_HERE将此粘贴给任何已连接 IOTools MCP 服务器的代理,再加上您的输入内容。
嵌入式小组件
<iframe
src="https://iotools.cloud/embed/conventional-commit-message-formatter/"
width="100%" height="520" frameborder="0" scrolling="no" loading="lazy"
title="约定式提交消息格式化工具 — iotools.cloud"
sandbox="allow-scripts allow-forms allow-same-origin allow-downloads allow-popups allow-popups-to-escape-sandbox"
allow="clipboard-write"
style="width:100%;border:1px solid #e5e7eb;border-radius:12px;overflow:hidden"></iframe>
<script src="https://iotools.cloud/embed.js" async></script>把它放到您自己的页面上——免费,无需密钥,只需保留一个反向链接。
| 每次 API/MCP 调用费用 | 5 积分起 |
|---|---|
| 需要更多积分? | 查看定价 |
也可通过
使用指南
约定式提交(Conventional Commits)是一个严格的、机器可读的提交消息格式标准:
包含一个类型、可选的范围、简短描述，以及可选的正文/页脚部分。诸如commitlint、semantic-release和
自动变更日志生成器之类的工具都会解析这种确切的格式 — 即使是一个错误的字符(缺少冒号、多余的空格、错误的
页脚语法)，提交也会无声地失败验证或从变更日志中被跳过。该工具根据表单构建符合规范的消息，以确保格式始终正确，
并且还可以将现有消息反向解析为其各个部分。所有操作都在浏览器中进行。
使用方法
- 选择创建消息。
- 选择一个类型(
feat、fix、docs等)，并可选择一个范围 (受影响的代码库区域，例如api或parser)。 - 用祈使语态写一个简短的描述(比如"添加"而不是"已添加")。
- 如果提交破坏向后兼容性，选中破坏性变更并描述该破坏 — 它将按照规范的要求，
作为
BREAKING CHANGE:页脚和类型/范围后的!被添加。 - 添加一个可选的正文用于更详细的说明，以及页脚用于诸如
Refs: #123或Reviewed-by: Name之类的信息(每行一个)。 - 将格式化后的消息直接复制到
git commit -m "..."或编辑器的提交消息框中。
切换到解析消息进行反向操作: 粘贴现有的提交消息，该工具会将其解析回类型、范围、 破坏性变更标志、描述、正文和页脚 — 用于检查他人编写的消息是否真正遵循规范。
主题行长度
主题行检查表将格式化后的标题(type(scope)!: description)与常用的 72 字符限制进行
比较，以便在提交前捕获那些会在git log --oneline或GitHub提交列表中被截断的较长
主题行。
提交类型
feat和fix与语义化版本(Semantic Versioning)中的语义
版本号升级直接对应(当semantic-release等工具读取您的历史时)，BREAKING CHANGE
页脚(或!)无论什么类型都会触发主要版本升级。其余的 — docs、style、refactor、
perf、test、chore、ci、build、revert — 在不影响版本号的情况下描述变更。
这可以替代commitlint这样的提交钩子吗?
不能 — commitlint 在提交时(通常通过Git钩子)验证提交，目的是在团队工作流中自动运行。 该工具用于手动编写一条消息，或在粘贴前检查消息。两者一起使用: 使用该工具编写消息， 使用commitlint自动应用规则。
如果我需要审查整个提交历史而不是单个消息该怎么办?
使用Git日志格式化工具 / 美化器将git log输出转换为
表格、列表或JSON — 或使用Git速查表查看常见的Git命令。