commit-message-writer

描述

基于 git diff、代码片段或纯文本描述，自动生成符合 Conventional Commit 规范的提交信息。同时支持生成 PR 标题及包含三个要点的 PR 摘要。适用于任意编程语言和任意项目——无需配置，开箱即用。

适用场景

• “写一条提交信息”
• “我该以什么内容提交这次变更”
• “为这段 diff 生成一条 Conventional Commit”
• “生成 PR 标题和描述”
• 任何需要提交信息的 git diff 或代码变更

支持的规范

• Conventional Commits 1.0（默认）
• Angular 提交格式
• GitHub squash-merge 风格
• 纯描述性风格（无约定）

可显式指定任一规范；若未指定，则默认使用 Conventional Commits。

输入

请粘贴以下任意一种内容：

• git diff（例如：git diff --staged）
• 对变更的简要描述（例如：“我在 API 中添加了速率限制”）
• 变更前/后的代码

可选地指定以下参数：

• 规范（默认为 Conventional Commits）
• 作用域（受影响的组件、模块或功能区域）
• 是否为破坏性变更（breaking change）

输出格式

## 提交信息

[type]([scope]): [subject]

[正文 — 解释“为何”要进行此项变更，而非仅复述“做了什么”。若主题已足够清晰，则可省略正文]

[BREAKING CHANGE: 描述 — 仅当适用时]
[Closes #123 — 仅当已知关联 issue 编号时]

---

## PR 标题
[简洁、祈使语气、不超过 70 个字符]

## PR 摘要
- [发生了什么变更]
- [为何进行此项变更 / 解决了什么问题]
- [是否存在显著副作用、注意事项或需后续跟进事项]

Conventional Commits 类型参考指南

撰写规则

• 主题行（subject）：使用祈使语气（如 “add”、“fix”、“remove”，而非 “added”、“fixed”、“removes”）
• 主题行（subject）：末尾不加句号
• 主题行（subject）：长度不超过 72 个字符
• 正文（body）：重点说明“为何”要进行此项变更，而非简单复述 diff 内容
• 破坏性变更：必须在 footer 中包含 BREAKING CHANGE: 并附上迁移说明
• 作用域（scope）：使用模块名、文件名或功能名称（例如：auth、api、db、ui）
• 若 diff 涉及多个关注点：建议拆分为多个独立提交

示例

简单修复

fix(auth): 在校验声明前拒绝已过期的 JWT token

此前，token 过期检查被安排在声明校验之后，
这使得攻击者可重放带有有效声明但已过期的 token。

含破坏性变更的新功能

feat(api)!: 所有公开端点均需提供 API key

BREAKING CHANGE: 所有请求现均需携带 `X-API-Key` 请求头。
使用匿名访问的客户端将收到 401 响应。详见迁移指南。

依赖项更新

chore(deps): 将 openssl 从 1.1.1 升级至 3.0.8

修复 CVE-2023-0286（X.400 地址类型混淆漏洞）。
无 API 变更。

自我优化说明

每次生成提交信息后，请记录本次输入类型是 diff、描述还是代码片段。累计使用达 20 次后，自动汇总最常缺失的上下文信息——这些缺失往往导致生成的信息质量下降。