name: commit-work description: “创建高质量的Git提交：审查/暂存预期更改，分割成逻辑提交，并编写清晰的提交消息（包括Conventional Commits）。当用户请求提交、制作提交消息、暂存更改或将工作分割成多个提交时使用。”
提交工作
目标
创建易于审查和安全部署的提交：
- 只包含预期更改
- 提交具有逻辑范围（必要时分割）
- 提交消息描述更改了什么以及为什么
询问的输入（如果缺失）
- 单个提交还是多个提交？（如果不确定：当有无关更改时，默认使用多个小提交。）
- 提交风格：必须使用Conventional Commits。
- 任何规则：最大主题长度，必需的范围。
工作流程（检查清单）
- 暂存前检查工作树
git statusgit diff（未暂存）- 如果更改很多：
git diff --stat
- 决定提交边界（必要时分割）
- 分割依据：功能 vs 重构，后端 vs 前端，格式 vs 逻辑，测试 vs 生产代码，依赖升级 vs 行为更改。
- 如果更改在一个文件中混合，计划使用补丁暂存。
- 只暂存属于下一个提交的内容
- 对于混合更改，优先使用补丁暂存：
git add -p - 取消暂存一个块/文件：
git restore --staged -p或git restore --staged <路径>
- 对于混合更改，优先使用补丁暂存：
- 审查实际将要提交的内容
git diff --cached- 合理性检查：
- 没有秘密或令牌
- 没有意外的调试日志
- 没有无关的格式更改
- 在编写消息之前，用1-2句话描述暂存的更改
- “更改了什么？” + “为什么？”
- 如果不能清晰描述，提交可能太大或混合；返回步骤2。
- 编写提交消息
- 使用Conventional Commits（必需）：
type(scope): 简短摘要- 空行
- 正文（什么/为什么，不是实现日记）
- 如果需要，页脚（BREAKING CHANGE）
- 对于多行消息，优先使用编辑器：
git commit -v - 如果有帮助，使用
references/commit-message-template.md
- 使用Conventional Commits（必需）：
- 运行最小的相关验证
- 在继续之前，运行仓库中最快的有意义的检查（单元测试、代码检查或构建）。
- 重复下一个提交，直到工作树干净
交付物
提供：
- 最终的提交消息（s）
- 每个提交的简短摘要（什么/为什么）
- 用于暂存/审查的命令（至少：
git diff --cached，加上任何运行的测试）