Diff → Conventional Commit

粘贴 git diff，自动从更改的文件推断 type/scope 并生成提交消息模板。支持 Conventional Commits 格式、验证主题行 50 字符限制、检测 BREAKING CHANGE，并生成可直接发送给 AI 的提示词。

完全免费无需注册浏览器内完成 5 种语言深色模式

提示词模板: 📚 Prompt Library →

git diff

📋 如何获取 diff

# 全部变更
git diff

# 仅已暂存的内容
git diff --cached

# 指定的某次提交
git show abc123

# 仅文件名（diff 过大时）
git diff --stat

改动文件

增/删

+0 / -0

推测 type

推测 scope

提交消息模板

0 字符 — 50/72

AI 提示词

📖 常见的坑

粘贴 git diff 的输出，本工具会依据变更文件与增删行数推断 type 与 scope，并组装出 Conventional Commits 格式的提交信息模板，以及可交给 AI 的提示词。处理全部在浏览器内完成。能推断的只到「改了什么」，而「为什么改」在 diff 中的任何地方都没有写——而后来阅读的人真正想知道的，永远是后者。

情形	会发生什么	怎么处理
推断出的 type 与实际不符	type 是根据文件路径与扩展名推断的，因此即便改动同一处，意图不同也无法区分。改了测试文件会推断为 `test`，但如果那是随缺陷修复而更新的期望值，`fix` 才更贴切。`docs` 与 `chore`、`refactor` 与 `fix` 之间的界线，同样无法从 diff 判断。	请把推断当作起点，并务必自行覆盖。拿不准时的判据是「从用户视角看，行为是否发生了变化」。变了就用 `feat` 或 `fix`，没变就用 `refactor` / `chore` / `test` / `docs`。这条判据在自动生成发布说明时会直接见效——只有值得展示给用户的变更才会落入前两类，事后无需再人工筛选。
一个提交里混了多种改动	当推断出的 scope 为 `()` 或多个时，这是提交粒度过大的信号。若缺陷修复、重构、依赖升级都塞进同一个提交，日后想 `git revert` 时连不想回退的部分也会一并回退*。它同样会削弱 `git bisect`：命中的提交越大，定位范围就越模糊。	请用 `git add -p` 按 hunk 分批暂存，按语义逐个提交；即便工作区已经混在一起，也能用这种方式拆分。判据是「能否用一句话描述这个提交」——如果句子里需要「并且」，就该拆。把拆分后的各个 diff 分别粘贴到本页面，即可分别得到模板。
把 diff 交给 AI，只得到一段摘要	只交出 diff，模型看到的就只有代码的变化。于是返回的往往是「添加了……」「修复了……」这类把 diff 已经显示的内容换个说法而已。提交信息的价值恰恰在于记录 diff 无法告诉你的东西，这样的信息等于白写。	在交出生成的提示词之前，请用自己的话补上一两行「为什么做这个改动」。哪怕只加入一条外部事实——「每月有 3 起超时报告」「因法规变更税率调整」——返回内容的质量就会不同。此外写上相关 Issue 编号，半年后阅读的人就能顺藤摸瓜找到来龙去脉。模板可参考提示词库。

遵循 Conventional Commits 的实际收益，在于可以从提交信息自动生成 CHANGELOG 与版本号：semantic-release 之类的工具会把 fix 映射为补丁版本、feat 映射为次版本、含 BREAKING CHANGE 的映射为主版本。反过来说，只要混进一个不守规范的提交，该次发布的自动化就不再可信。若要采用，请把 commitlint 放进 pre-commit 钩子，让机器来守住格式——仅靠人的自觉而长期维持的规范，从来没人见过。

📖 使用方法

1

复制 diff

`git diff` 输出
2

粘贴并推测

自动检测
3

复制并提交

复制 → commit

❓ 常见问题

type 如何检测？

根据路径 / 扩展名推测

需要 AI？

仅模板足够

🐛 此工具出现问题了吗？

免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。

Diff → Conventional Commit

📖 常见的坑

📖 使用方法

❓ 常见问题

感谢您的反馈！