根据 git diff 或改动描述生成规范的提交信息，遵循 Conventional Commits 规范。适用于提交代码前整理 commit message、把一句随手写的说明改写成结构化提交、或为历史提交补写说明时使用。
Downloading requires signing in first (free registration — just a username and password).Sign in →
13 automated checks on metadata, examples, executability and completeness, for authors to self-improve; does not affect user ratings.
# Commit Message Writer 把一个 `git diff` 或一段口语化的改动描述，转成一条能被工具链识别的规范提交信息。 ## 何时使用 - 提交前手头只有一个 diff，不知道怎么写清楚 - 团队要求遵循 Conventional Commits，但经常写歪 - 一次改动混了几件事，需要判断该不该拆分提交 - 给别人的 PR 提建议时，顺手给一条规范的提交信息 不适用的场景：合并提交（merge）、回滚提交（revert）、以及单纯改文档错别字这种一眼能看完的改动，直接写一句话更快。 ## 步骤 1. **读改动**：看 `git diff --staged` 或用户贴的 diff。没有 diff 时，让用户用一句话说明改了什么、为什么改。 2. **判断类型**：从下表选一个，拿不准时优先选改动影响最大的那个。 3. **定范围**：取改动最集中的目录或模块名，没有明确模块就省略。 4. **写标题**：祈使句、现在时、不超过 50 字符、结尾不加句号。 5. **写正文**（可选）：说明「为什么改」而不是「改了什么」，改动本身 diff 里已经有了。 6. **标破坏性变更**：有不兼容改动时，标题加 `!`，正文加 `BREAKING CHANGE:` 段。 ## 类型对照 | 类型 | 用于 | | --- | --- | | feat | 新增功能 | | fix | 修复缺陷 | | refactor | 不改行为的重构 | | perf | 性能优化 | | docs | 只改文档 | | test | 增删改测试 | | build | 构建系统或依赖 | | ci | CI 配置 | | chore | 杂项，不该出现在用户可见的变更里 | ## 输出格式 ``` <type>(<scope>): <subject> <body> <footer> ``` 示例： ``` feat(auth): add SMS verification for signup Phone numbers were being accepted without verification, which let throwaway accounts through. Verification codes expire in 5 minutes and are limited to 3 attempts per number. Closes #128 ``` 破坏性变更： ``` refactor(api)!: drop v1 response envelope BREAKING CHANGE: clients reading `data.items` must switch to `items`. The v1 envelope is removed in this release; see MIGRATION.md. ``` ## 自检清单 提交前逐条确认： - 标题能独立说清这次改动，不需要看正文 - 类型选的是影响最大的那个，不是最省事的 `chore` - 正文解释的是动机，不是逐行复述 diff - 一条提交只做一件事；混了两件事就拆开 - 没有 `fix bug`、`update code`、`优化一下` 这类零信息量的标题 ## 边界与注意 - 不要臆造 issue 编号，不知道就留空，别写 `Closes #0` - 不要替用户决定拆分策略后直接输出多条提交；先说明拆分建议，等确认 - diff 超过 500 行时，先概括改动涉及的模块，再问哪一部分是重点 - 生成的语言跟随用户：用户用中文描述就用中文写提交信息，英文同理 - 团队有自己的规范（如 Angular、Gitmoji）时，以团队规范覆盖默认值
Shrimp Assistant