commit-work

# 提交工作 ## 目标 进行易于审查且安全发布的提交： - 仅包含预期的变更 - 提交具有逻辑范围（必要时拆分） - 提交信息描述了变更内容及原因 ## 需要询问的输入（如果缺失） - 单次提交还是多次提交？（如果不确定：当存在无关变更时，默认为多次小提交。） - 提交风格：必须使用约定式提交（Conventional Commits）。 - 任何规则：主题行的最大长度、必需的范围（scope）。 ## 工作流（检查清单） 1) 在暂存前检查工作区 - `git status` - `git diff` (未暂存) - 如果变更很多: `git diff --stat` 2) 确定提交边界（必要时拆分） - 拆分依据：功能 vs 重构、后端 vs 前端、格式化 vs 逻辑、测试 vs 生产代码、依赖升级 vs 行为变更。 - 如果一个文件中混合了多种变更，计划使用补丁暂存。 3) 仅暂存属于下一次提交的内容 - 混合变更优先使用补丁暂存: `git add -p` - 取消暂存某个代码块/文件: `git restore --staged -p` 或 `git restore --staged ` 4) 审查即将提交的内容 - `git diff --cached` - 安全检查： - 无密钥或令牌 - 无意外的调试日志 - 无无关的格式化变动 5) 用 1-2 句话描述暂存的变更（在编写信息之前） - "变更了什么？" + "为什么？" - 如果无法清晰描述，说明提交可能太大或太杂；回到第 2 步。 6) 编写提交信息 - 使用约定式提交（必须）： - `type(scope): short summary` - 空行 - 正文（变更内容/原因，而非实现日志） - 页脚（BREAKING CHANGE，如果需要） - 多行信息优先使用编辑器: `git commit -v` - 如果有帮助，使用 `references/commit-message-template.md`。 7) 运行最小的相关验证 - 在继续之前运行仓库中最快的有效检查（单元测试、lint 或构建）。 8) 重复上述步骤，直到工作区干净为止 ## 交付物 提供： - 最终的提交信息 - 每个提交的简短总结（内容/原因） - 使用的暂存/审查命令（至少包括：`git diff --cached`，以及运行的任何测试）