Menu
Git 改动需编写规范提交信息时。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
需求模糊、含隐藏假设或 X-Y problem，需先澄清再动手时。
审查代码（自己的或别人的），需有重点、分层次地看时。
遇到 bug、报错、崩溃或行为异常，需定位根因时。
设计或改进错误处理与日志时。
在 Lion-Skills 仓库创建或修改 skill 时。
为代码标识符（变量/函数/类/文件/API/数据库字段）决定名字时。
| name | commit-message |
| description | Git 改动需编写规范提交信息时。 |
把一团 diff 提炼成规范、可追溯的提交信息。核心：一条提交说清"做了什么"和"为什么"，让未来的自己（和同事）能从提交历史里读懂项目演进。
不该用：还没写完代码（先写代码）；只想看 diff（用 git diff）。
<type>(<scope>)<!>: <subject>
<body 可选：为什么改>
<footer 可选：BREAKING CHANGE: ... / Closes #123>
破坏性变更（不向后兼容的改动）两种写法，二选一或并用：
! 标记：紧贴 type/scope 之后、冒号之前，如 feat(api)!: 改用 token 鉴权替代 cookie——一眼标红，提醒 reviewer 注意。BREAKING CHANGE:：放 footer，写清破坏了什么、怎么迁移，如 BREAKING CHANGE: /api/login 改为返回 token，前端需改用 Authorization 头——给受影响方具体的迁移指引。破坏性变更必须二选一明确标注，别藏在普通提交里让下游踩坑。
type 选一个：feat（新功能）、fix（修 bug）、docs（文档）、refactor（重构不改行为）、test（测试）、chore（构建/杂务）、perf（性能）。带可追溯业务变更的迁移脚本（如新增用户表）可算 feat，纯基础设施改动算 chore。
auth、api、ui）可省略。git add -p 分块暂存）判断"相不相关"：这些改动服务于同一个目的吗？是 → 一条；否 → 拆。
灰色地带——"主线 + 顺带小修复"：重构或加功能时顺手修了个同处的小 bug（例 1 就是这种），可以合并：主线作 subject，bug 修复在 body 一行带过。但若两件事跨文件、跨关注点、或各自都够大，就该拆。一个简单的尺子：能不能用一句话（一个 subject）概括全部改动？能 → 合；不能 → 拆。
写为什么和影响，不写代码细节（代码自己会说话）：动机/背景、副作用/破坏性变更的迁移说明、关联 issue/PR（如 Closes #123）。破坏性变更的标注方式见上面「格式」节。subject 够清楚的小改动可以只写 subject，别硬凑 body。
subject 跟随仓库现有风格（多数中文团队和本仓库用中文 subject；Conventional Commits 生态也常见英文）——没有仓库上下文时跟随团队语言；body 语言同 subject；用户明确偏好优先。
例 1（单改动） — 把 useState 换成 useReducer：
refactor(auth): 用 useReducer 替换登录表单的状态管理
复杂的状态转换用 reducer 更清晰，也为后续多步校验做准备。
顺带修了 useEffect 未清理订阅导致的内存泄漏。
例 2（多相关改动） — 加登录接口 + 测试：
feat(auth): 实现邮箱密码登录接口
- 新增 /api/login 端点
- 加密码哈希校验
- 补单元测试覆盖成功/失败场景
例 3（该拆的） — 登录接口、迁移脚本、README 三件不相关事，拆三条：
feat(auth): 实现登录接口
chore(db): 添加用户表迁移脚本
docs: 更新 README 部署说明
| 问题 | 修法 |
|---|---|
| 太笼统（"update""改了点"） | 写清 type + 具体做了什么 |
| 一条提交塞多个无关改动 | 拆成多条 |
| subject 写"怎么做"而非"做了什么" | "用 useReducer 替换"而非"改了 state 逻辑" |
| 只说现象不说动机 | body 补上为什么 |