commit-creator

创建提交

确定操作

• 仅请求消息时，输出文本。仅请求实现时，将已检查的工作树修改保留在本地，并保留暂存状态。
• 仅在用户授权范围内提交、改写历史或推送。提交请求涵盖创建提交及所需的暂存操作，不包括改写历史或推送。创建 PR 包含其任务提交和推送。已完成的提交或发布请求不涵盖后续修复，除非有持续生效的指令。

检查修改

根据仓库状态确定提交消息，不能只依赖对话记忆：

git status --short --branch
git diff --cached
git diff

找出属于所请求提交的具体行为、文件、软件包、问题引用和版本变更。如果没有实质性修改，请停止，不要编造提交消息。

选择分支和范围

检查当前分支，并在可用时检查远程默认分支：

git fetch origin --prune
git branch --show-current
git ls-remote --symref origin HEAD

• 提交前，如果当前分支落后于上游分支或最新的远程默认分支，或与其分叉，请先报告。仅当适用的用户授权涵盖合并、变基或改写历史时，才执行这些操作。
• 如果当前分支是默认分支，且用户未明确要求在该分支提交，请询问是创建分支还是提交到默认分支。如果用户指定了目标分支，或明确表示要在当前分支提交，则无需再次询问，直接继续。
• 为已知任务创建分支时，请遵循项目的命名约定，并保留跟踪 ID 的原始大小写，例如 feat/gh-42-session-cache 或 fix/APP-123-token-refresh。如果仅凭 ID 无法确定归属，请注明仓库或项目。

保留暂存状态

• 使用已确认的提交范围，无需再次询问。对于互不相关的任务文件，使用路径限定的提交，并仅添加未跟踪的任务文件；保留无关的暂存内容。如果任务修改与无关修改在同一文件中重叠，且预期结果不明确，请在提交前询问。
• 如果只有已暂存的修改，且没有更具体的范围，则提交这些已暂存的修改。
• 如果只有未暂存的修改，且没有更具体的范围，则暂存所有当前修改。
• 如果已暂存和未暂存的修改同时存在，且范围尚未确认，请询问是仅提交已暂存的修改，还是暂存全部修改。
• 除非用户明确要求，否则绝不取消暂存或重新暂存用户已暂存的文件。

对修改分组

每个提交只包含一个逻辑功能或独立修改，并包含相关测试和文档。独立的依赖更新和无关工作应分开处理。一个 PR 可以包含多个提交。

1. 默认将修正作为新提交。对已合并内容的修正始终使用新提交。
2. 更新某个提交时，使用提交历史和差异来找到匹配的提交；如果目标不明确，请先询问。保留独立提交和无关的暂存内容。

编写消息

用英文编写完整消息：

<type>(<scope>): summary

- {emoji} concrete change
- {emoji} concrete change

• 摘要不超过 50 个字符，使用祈使语气，且不加句号。
• 使用准确的软件包或模块作为作用范围；仅在确实涉及多个软件包时使用 all。
• 除非用户明确要求仅写主题消息，否则正文至少包含一条具体的项目符号。
• 每条项目符号只描述一项逻辑变更，项目符号之间不要留空行。
• 只有在确实存在破坏性变更时，才添加 ! 和 BREAKING CHANGE: 页脚。
• 根据请求、分支名称或代码库上下文解决任务。若当前会话中的任务要求和差异分析适用于当前提交，则重用这些信息；若缺少上下文，则从正确的跟踪系统中读取。在选择关闭引用之前，先询问缺失的任务证据或不明确的完成情况。
• 当提交完成了已核实的 GitHub issue 时，在正文中添加关闭引用：同一代码库使用 Fixes #42，其他代码库使用 Fixes owner/repo#42。无需再次询问用户确认已知任务。
• 对于部分解决方案，使用常规引用，例如 Refs #42。对于其他跟踪系统中的任务，请附上已核实的任务键和 URL。

使用以下类型：feat ✨、fix 🐛、docs 📚、style 💄、refactor ♻️、perf ⚡、test ✅、build 🔧、ci 👷、chore 🔨、revert ⏪。

依赖项更新

分别列出每项已更改依赖项的旧版本和新版本：

- 📦 package-name: old-version -> new-version

不要用笼统的依赖项更新项目符号代替该列表。

创建提交

• 对于仅涉及提交的请求，不要额外运行项目检查。如果用户提出要求、同一任务修改了文件且代码库说明要求验证，或需要诊断失败的钩子，则运行检查。
• 使用一个 -m 指定摘要，再用一个 -m 指定完整正文；如果多行引用不便，则使用 git commit -F-。
• 不要为每条项目符号单独传入一个 -m，因为 Git 会将它们分别转换为一个段落。
• 不要为 git commit 设置执行超时。等待 Git 和所有钩子自然退出。Git 钩子可能静默运行数分钟，超时可能会在必要检查完成之前终止它们。
• 报告确切错误，并提出修复、留给用户处理或使用 --no-verify。
• 未经用户明确批准，绝不要绕过钩子。
• 需要示例时，请参阅 references/examples.md。