commit-work

提交工作

目标

创建易于审查且可安全发布的提交：

• 只包含预期的更改
• 提交的逻辑范围清晰（必要时拆分）
• 提交消息说明更改内容及原因

需要询问的输入（若缺失）

• 单个提交还是多个提交？（如果不确定：存在无关更改时，默认拆分为多个小提交。）
• 提交风格：必须使用 Conventional Commits。
• 任何规则：主题行最大长度、必需的作用域。

工作流（检查清单）

1. 暂存前检查工作树
   • git status
   • git diff（未暂存）
   • 如果更改很多：git diff --stat
2. 确定提交边界（必要时拆分）
   • 按以下类别拆分：功能与重构、后端与前端、格式调整与逻辑、测试与生产代码、依赖升级与行为更改。
   • 如果同一文件中包含多类更改，计划使用补丁暂存。
3. 只暂存属于下一个提交的内容
   • 混合更改优先使用补丁暂存：git add -p
   • 取消暂存某个代码块或文件：git restore --staged -p 或 git restore --staged <path>
4. 检查实际将要提交的内容
   • git diff --cached
   • 基本检查：
     • 没有密钥或令牌
     • 没有意外的调试日志
     • 没有无关的格式调整
5. 编写提交消息前，用 1-2 句话描述暂存的更改
   • “更改了什么？”+“为什么？”
   • 如果无法清楚地描述，说明这个提交可能过大或内容混杂；返回第 2 步。
6. 编写提交消息
   • 必须使用 Conventional Commits：
     • type(scope): short summary
     • 空行
     • 正文（说明内容和原因，而非实现过程）
     • 需要时添加页脚（BREAKING CHANGE）
   • 多行消息优先使用编辑器：git commit -v
   • 如有帮助，可使用 references/commit-message-template.md。
7. 运行最精简的相关验证
   • 继续之前，运行代码库中最快且有意义的检查（单元测试、lint 或构建）。
8. 重复上述步骤，提交后续更改，直到工作树干净

交付内容

提供：

• 最终提交消息
• 每个提交的简短摘要（内容和原因）
• 用于暂存和审查的命令（至少包括：git diff --cached，以及运行过的任何测试）