commit-changes

提交更改时，请遵循以下工作流：

此技能仅根据已审核的暂存更改创建普通的新提交。 绝不能创建合并提交或压缩提交： 不要运行 git merge、git merge --no-ff、git merge --squash、 git rebase --autosquash、用于合并提交的 git commit --amend， 或任何等效的历史合并操作。

1. 分析工作区：运行 git status 和 git diff（包括已暂存和未暂存的更改），了解所有更改。

2. 按语义分组更改：识别逻辑工作单元。每个提交都必须是原子性的——每个提交只包含一项功能更改。将共同实现单一关注点的相关文件分组。

3. 编写 Conventional Commits 格式的提交消息：使用格式 <type>(<scope>): <description>，可选择添加正文。允许的类型：

   • feat：新功能
   • fix：错误修复
   • refactor：代码重构，不改变行为
   • docs：仅文档更改
   • style：格式、空格、分号（不改变逻辑）
   • test：添加或更新测试
   • chore：工具、配置、依赖项
   • perf：性能改进
   • ci：CI/CD 更改
   • build：构建系统更改
   • revert：撤销先前的提交

   在此格式基础上，还需遵循项目自身的约定。 编写第一条提交消息前，请阅读项目关于提交的说明——其 README.md（Contributing 部分）、CONTRIBUTING.md、FRAMEWORK.local.md 或同等文件——并查看近期的 git log。 项目可能要求在上述格式之外添加其他内容，例如在每条提交消息的主题中包含交付卡片的编号；如果文档与历史记录不一致，以文档为准。若在此处遗漏了某项约定，所有提交消息写完后才会发现，而要纠正就意味着必须逐条重写。

4. 提交规则：

   • 将主题行控制在一行内。如果变更需要主题行无法表达的背景信息——例如为何进行此变更、作出的权衡，或对其他工作的影响——请添加正文。正文与主题行之间空一行；如果主题行已经表达了所有内容，则省略正文。
   • 主题行或正文中都不得包含尾注、共同作者行、AI/工具归属信息、生成标记、机器人签名，或暗示涉及 AI 的元数据。
   • 每次提交都使用 git add 指定具体文件；除非所有变更都属于同一次提交，否则绝不使用 git add .。
   • 每次提交前立即运行 git diff --cached --name-only，并且仅在结果与当前分组相符时提交。 文件名属于你，并不意味着暂存区也属于你：git rm、git mv 和先前中断的分组都会暂存变更，而且这些变更会一直留在暂存区，因此之后运行 git add <one file> 时，也会把它们一并提交。这样产生的提交会包含两项变更，但提交信息只描述其中一项——而这在审查中无从察觉，因为提交信息读起来确实没错。
   • 每次提交后，运行 git log -1 --format=%B，确认最终提交信息不包含任何与 AI 相关的归属信息或元数据，然后运行 git status 验证是否成功。
   • 如果某个文件混有本次变更和其他人尚未提交的无关工作，需要按代码块暂存，而不是决定纳入或跳过整个文件。 git add <file> 会暂存文件中的所有代码块，这会导致无关工作被带入提交，或者迫使你让自己的变更留在暂存区之外。先隔离出自己的代码块——运行 git diff -- <file>，根据其 @@ 标头识别代码块——然后创建一个只包含这些代码块的补丁文件，并通过 git apply --cached 仅暂存它们（每个代码块都需要相同的 diff --git 标头，但各自使用独立的 @@ 块；git apply 会根据上下文定位，因此省略其他代码块导致标注的行号偏移并不影响应用）。运行 git diff --cached -- <file>（确认其中只有你的代码块）和 git diff -- <file>（确认只有其余部分仍在工作树中，且未被触动），验证拆分结果。在一个区域内的每次变更都会改动同一个大型共享测试文件的代码库中，这种情况确实会发生，并非假设情形。

5. 执行顺序：一次只暂存并提交一个分组。不要跳到后续分组。