commit

在保留预期范围外更改的同时，恰好创建一个连贯的提交。提交信息使用英文，并使用用户的语言与用户沟通。遵循用户的明确指示和适用的仓库指南，然后再采用以下默认规则。

仓库上下文

• 状态：!git status --short
• 已暂存的更改：!git diff --cached
• 未暂存的更改：!git diff
• 未跟踪的文件：!git ls-files --others --exclude-standard
• 未合并的文件：!git diff --name-only --diff-filter=U
• 当前分支：!git branch --show-current
• 最近的提交：!git log --oneline -10

1. 确定提交范围

1. 如果工作树和索引中均无更改，告知用户没有内容需要提交，然后停止。
2. 按以下顺序选择目标更改：
   • 如果用户指定了文件或逻辑变更，则采用该范围。如果已有不相关的更改被暂存，在更改索引前说明冲突并询问如何处理。
   • 否则，如果存在已暂存的更改，则将已暂存的差异视为完整目标。保留未暂存和未跟踪的更改，不作处理。
   • 否则，按用途对未暂存和未跟踪的更改分组。如果它们构成一个明确的逻辑变更，则采用该组。如果存在多个可能的分组，或某个文件是否应纳入并不明确，则列出各组并询问要提交哪一组。
3. 根据行为和用途判断更改是否连贯，而不是只看文件数量。将直接支持实现的测试、文档和配置一并纳入。

2. 准备索引

如果确切的目标尚未暂存，则使用明确的路径规格仅暂存目标文件：

git add -- "path/with[brackets]/file.ts" "another path/file.md"

路径前使用 --，并为包含空格、方括号、圆括号、通配符或其他 shell 特殊字符的路径加引号。仅在未跟踪文件属于目标更改时才将其纳入。除非仓库指南明确要求跟踪本地配置、凭据、临时文件、日志和构建产物，且这些内容是此更改所必需的，否则将其排除。如果目标文件中混有相关和无关的代码块，则仅暂存相关代码块；如果无法安全地部分暂存，先询问用户，再暂存整个文件。

暂存后，重新运行 git status --short 和 git diff --cached。此时，已暂存的差异是提交的唯一依据。

3. 审查已暂存的差异

如果存在以下任何阻止提交的情况，请先停止，不要提交：

情况	必须采取的操作
已暂存差异为空	告知用户此提交没有已暂存的内容。
存在未合并条目或实际冲突标记	列出受影响的文件，并请用户解决冲突。
疑似包含秘密、凭据、私钥或非预期的 .env 文件	指出其位置，但不要复述内容；请用户移除该内容，或确认其为非机密测试数据。
已暂存内容不明确或与目标无关	说明不匹配之处，并询问如何确定提交范围。

还要检查新增行，确认是否意外包含调试语句、生成的输出、日志，以及无法解释的 TODO 或 FIXME 标记。仅当某项看起来并非有意添加时才询问；不要将每次出现都视为错误。

4. 撰写消息

将消息视为一段简洁、独立的说明，供可能不会检查差异的读者或编码 Agent 阅读。优先说明行为变化或系统规则，而不是作者的操作、文件清单和实现 细节。每项陈述都必须以暂存的更改和相关仓库背景为依据。

首先遵循明确的仓库提交规范。将近期提交历史用作辅助证据，而不是书面 指南的替代。然后提炼：

1. 行为、能力、数据流或系统规则在更改前后的主要变化。
2. 能解释大部分暂存差异的单一核心思路。
3. 仅保留防止读者形成错误认知所必需的背景。

如果没有定义规范，请使用以下默认规则：

• 标题（主题）： 以英文祈使动词开头。指出受影响的概念及其变化后的行为或 适用规则，而不只是编辑操作或笼统的好处。优先使用 Deduplicate retries by request ID， 而不是 Update retry handling。省略末尾句号，标题保持简洁，不超过 72 个字符。不要包含约定式提交类型或范围（feat:、fix(x):）、工单或问题 ID，以及分支名称。近期提交包含此类前缀，不足以成为添加前缀的理由；只有明确的 书面规范（例如 CONTRIBUTING.md、提交模板或 commitlint 配置）才可以。
• 说明（正文）： 默认使用一个简短段落，首句说明读者可以验证的变化：之前 是什么规则，现在又是什么规则。Previously, <old rule>. Now, <new rule>. 是一种 自然表达方式，但不是硬性要求。如果没有有意义的既有行为（例如新能力、新文件或 首个版本），就直接说明新规则；绝不要写出“之前”从句只是对“现在”从句进行 否定的对比。仅在决定单位、方向或未变边界属于该变化本身时才纳入。不要总结文件 或测试。只有标题本身已足以让人理解变化时，才省略正文。
• 只有当具体输入、状态或输出能让不明显的规则更容易理解时，才使用一个最简示例。 例如：Attempts r1, r1, r2 now create two jobs instead of three because request ID defines identity. 示例必须忠实于差异；不要编造没有依据的行为。
• 在说明核心思路后，仅当动机、重要约束或权衡、破坏性变更或迁移指南能实质性地 帮助读者理解或采取行动时，才补充这些内容。
• 标题与说明之间空一行，正文每行不超过 72 个字符。

不要将说明写成逐文件或逐代码块的总结。省略次要编辑、常规测试和机械性细节， 除非它们改变了核心认知模型。不要仅因为更改规模较大，就强行添加正文或示例。

5. 验证并提交

执行提交前，最后检查一次 git diff --cached 并确认：

1. 每项暂存的更改都属于选定范围。
2. 提交消息准确概括暂存更改的核心思路，无需逐个检查文件，也不声称包含未暂存的工作。
3. 暂存差异仍通过上述安全审查。

对于仅包含主题的消息，运行：

git commit -m "Subject line"

对于包含正文的消息，使用多个单独的 -m 参数，让 Git 插入真正的空行。较长的正文中应使用实际换行；切勿将换行编码为字面量 \n 文本。

git commit \
  -m "Deduplicate retries by request ID" \
  -m "Retries now treat request ID as the unit of identity. Attempts r1, r1,
r2 create two jobs instead of three."

如果提交失败，请先检查错误和当前状态，再采取进一步操作。如果钩子修改了文件或索引，请检查新的暂存差异，并在重试前重新验证提交消息。不要在未检查的情况下盲目重试。

成功后，使用 git log -1 --format='%B' 检查完整的已保存消息。确认标题与正文之间的分隔符以及正文中的换行都是真正的换行，而不是字面量 \n 文本。如果刚创建的消息格式有误，请使用实际换行修正后 amend，并再次检查。然后运行 git log -1 --format='%h %s' 和 git status --short。报告提交哈希和主题，然后说明任何仍未暂存或未跟踪的更改。除非用户另行要求，否则不要推送。