Git / 版本控制

Git 提交信息生成器

填写字段构建消息，或切换到校验检查完整文本；两种输入分别保留。

自动处理

消息输入

类型范围（可选）简短描述正文（可选）页脚（可选）

候选类型仅供参考，也可以输入自定义类型。

以 Refs: #42 或 Closes #42 开头，后续普通行接续前一个值。

消息结果

消息仅在当前浏览器处理，不读取仓库或发送网络请求。

输出选项

添加 ! 声明破坏性变更

检查 Conventional Commits 1.0.0 结构；不检查项目规则，不强制 50/72 字符。最多 20,000 个 UTF-16 单元。

请输入描述或完整消息。

准备提交时，最容易漏掉的往往不是类型名称，而是范围后的标点、正文前的空行，以及是否真的需要破坏性标记。Git 提交信息生成器把这些信息分开填写并组合展示。已有消息也可以直接检查；切换模式会保留另一边的草稿，不必为了检查一段文本重新填写所有字段。

为什么使用 Git 提交信息生成器

让段落边界一目了然

Git 提交信息生成器会补上标题标点以及标题、正文、页脚之间的空行。范围自动放入括号，简短描述保留在首行，正文内部的分段不被压缩。查看结果时可以同时确认标题长度和识别出的页脚数量，避免把说明误写进标题。

把破坏性声明单独核对

普通 feat 消息表示次版本变化，但加上 ! 或有效的 BREAKING CHANGE 页脚后就声明主版本变化。界面会显示这个差异；它不会读取代码来证明兼容性，也不会因为描述里出现“破坏性”三个字就自动升级声明。

先确认含义，再检查结构

常用类型只是输入建议

下拉建议包含 feat、fix、docs 等常用名称，也可以直接填写团队自定义类型。先判断改动的实际含义，再选择类型；Commit 规范生成器无法仅凭短描述判断代码是否真的修复了问题。

在页脚字段写明结构

正文允许多段文字。页脚第一行应使用 Refs: #42 或 Closes #42 这样的格式，后续普通行接续前一个值，新的合法标记才开启下一项。构建器负责补空行，用户负责页脚内容。

留意何时需要重新处理

自动处理会等待 350 毫秒。关闭开关后显示操作按钮，也可以按 Ctrl/Cmd + Enter。字段、完整文本或 ! 选项改变时，旧结果立即失效；完成新一轮提交信息校验后才能导出。

从标题到多行页脚

自定义类型与原有大小写

约定式提交允许常用列表之外的类型。工具会保留 type、scope 和描述的大小写，FEAT 与 feat 在声明意图上相同。中文描述可以直接使用；标题长度只是计数，不会在 50 或 72 字符处被截断或判错。

完整消息检查与定位

校验模式检查标题、必需空行以及能够识别的页脚。错误保留具体行列，编辑器标出对应行。正文中的网址和普通冒号句子不会直接成为格式错误；从其他工具复制来的文本也不会被自动反填或改写成表单。

两种有效的 breaking 标记

! 放在类型或范围之后、冒号之前；单独使用时不要求额外页脚。也可以写 BREAKING CHANGE: 说明，或等价的 BREAKING-CHANGE: 说明。这个特殊标记必须大写，页脚值可以跨行，复制与下载只包含消息本身。

格式通过意味着什么

不代替仓库规则: 结构有效不代表通过项目的 commitlint 或提交钩子。本页不读取配置，不强制小写、祈使句或类型白名单，也不能判断 feat 与 fix 是否符合真实代码。团队要求需要在仓库中另行验证。
一次只检查一条消息: 输入最多 20,000 个 UTF-16 单元，构建后的标点和分隔空行也计入上限；超限会拒绝而不是截断。CRLF 与 CR 会转为 LF；构建时仅移除正文和页脚两端的换行，内部段落及空格保留。
页脚识别存在明确边界: 完整文本中，空行后的合法标记会开启页脚区，因此 Note: text 也可能被识别为页脚；带冒号的任意句子仍可作为正文。专用页脚字段的首行必须有合法标记及值，工具不会猜测或修正错误的分隔符。
不操作 Git 或计算发布版本: 本页不执行提交、修改历史、导入 diff、生成 shell 命令或用 AI 拟题，也不保存历史或生成分享链接。major、minor、patch 只说明消息的声明；其他类型没有隐式版本影响，撤销提交也不会自动抵消旧声明。
替换前可以检查并撤销: 示例与清空只影响当前模式。已有内容时先显示替换预览及 UTF-16 数量，应用后可以撤销一次，同时恢复输入、! 选项与结果。切换模式本身不覆盖另一份草稿，原始消息也不会被自动修复。