commit-smart

# 智能提交 (Smart Commit) 通过分析你的实际变更来创建有意义的 Conventional Commits。 ## 工作流 ### 第 1 步：评估工作树 运行以下命令以了解当前状态： bash git status git diff --stat git diff --cached --stat ### 第 2 步：处理未暂存的变更 如果没有任何内容被暂存（`git diff --cached` 为空）： 1. 向用户展示已更改的文件 2. 根据逻辑分组建议暂存内容（例如，“这 3 个文件都与 auth 重构相关”） 3. 询问用户是否要暂存全部，或选择特定文件 4. 使用 `git add ` 暂存已批准的文件 如果变更已暂存，则进行分析。 ### 第 3 步：分析 Diff 读取完整的暂存 diff： bash git diff --cached 根据变更确定提交类型： | 信号 | 类型 | |--------|------| | 具有新功能的新文件 | `feat` | | 新测试文件或测试添加 | `test` | | 对现有逻辑的修复 | `fix` | | 不改变行为的结构性变更 | `refactor` | | package.json, tsconfig, CI 配置变更 | `chore` | | 构建/打包工具配置变更 | `build` | | 仅 README, 文档, 注释 | `docs` | | 仅格式化, 空格, 分号 | `style` | | 性能改进 | `perf` | 根据受影响的主要目录或模块确定范围： - `src/api/` -> `api` - `src/components/auth/` -> `auth` - `tests/` -> `tests` - 根目录配置文件 -> 省略范围 - 多个不相关区域 -> 省略范围 ### 第 4 步：检查用户覆盖 如果用户通过 `$ARGUMENTS` 提供了参数： - 单个单词（例如 `fix`） -> 用作提交类型 - 两个单词（例如 `refactor api`） -> 用作类型和范围 - 其他情况 -> 使用自动检测的值 ### 第 5 步：撰写提交信息 格式：`type(scope): imperative short description` 规则： - 主题行最多 72 个字符 - 使用祈使语气（“add”, “fix”, “refactor”，而不是 “added”, “fixes”） - 不要以句号结尾 - 正文解释 **为什么** 进行此更改，而不是更改了什么（diff 显示了更改内容） - 如果更改微不足道（拼写修复、格式化），则跳过正文 示例： feat(auth): add JWT refresh token rotation Tokens were expiring mid-session for users with slow connections. Rotating refresh tokens extends the session without compromising security, since each refresh token can only be used once. ### 第 6 步：确认并提交 向用户展示建议的提交信息并请求确认。 如果确认，运行： ba