oh-my-git-commit

执行 git commit，支持 conventional commit 消息分析、智能暂存和消息生成。用户要求提交更改、创建 git commit 或提到 "/commit" 时触发。支持：(1) 从变更自动检测 type 和 scope，(2) 从 diff 生成 conventional commit 消息，(3) 交互式 commit 支持覆盖 type/scope/description，(4) 按逻辑分组智能暂存文件

Audits

Pass

ClawScanPass

Agentic behavior and permission review.

Static analysisPass

Pattern checks against bundled files.

VirusTotalPass

Multi-engine malware detections and file reputation.

Install

openclaw skills install oh-my-git-commit

Git Commit - Conventional Commits

概述

使用 Conventional Commits 规范创建标准化、语义化的 git commit。通过分析实际 diff 来确定合适的 type、scope 和 message。

Conventional Commit 格式

<type>[可选 scope]: <描述>

[可选正文]

[可选脚注]

Commit Type 对照表

Type	用途
`feat`	新功能
`fix`	Bug 修复
`style`	代码格式/样式调整（无逻辑改动）
`refactor`	代码重构（非 feature/fix）
`perf`	性能优化
`test`	添加/更新测试
`build`	构建系统/依赖变更
`ci`	CI/配置变更
`chore`	维护/杂项
`revert`	回滚 commit

破坏性变更

# 在 type/scope 后加感叹号
feat!: 移除已废弃的接口

# 或使用 BREAKING CHANGE 脚注
feat: 允许配置继承其他配置

BREAKING CHANGE: `extends` 键的行为已变更

工作流程

1. 分析 Diff

# 如果有已暂存的文件，使用 staged diff
git diff --staged

# 如果没有暂存文件，使用工作区 diff
git diff

# 同时查看状态
git status --porcelain

2. 暂存文件（如需要）

如果没有任何文件被暂存，或者你想按不同逻辑分组：

# 暂存指定文件
git add path/to/file1 path/to/file2

# 按模式暂存
git add *.test.*
git add src/components/*

# 交互式暂存
git add -p

禁止提交机密信息（.env、credentials.json、私钥等）。

3. 生成 Commit Message

先逐文件阅读 diff 内容，理解每处改动的具体功能和意图，然后生成结构化的 commit message。

必须包含以下部分：

Type：这是什么类型的变更？
Scope：影响哪个区域/模块？
Description：一句话概括变更内容（现在时、祈使句，不超过 72 字符）
Body（多文件或复杂变更时必须）：按文件/模块分组，列出每处核心改动的具体功能点

Body 撰写要求：

不要只写"优化样式"或"修复 bug"，要具体到改了什么、为什么改
多文件变更时，按文件分组，每行以 - 开头
涉及算法/逻辑变更时，说明新行为的规则和边界条件
涉及 UI 变更时，说明具体的交互或视觉效果改动
如果 diff 中有 TODO、FIXME 或明显的 hack，在 body 中注明

message 使用中文撰写，但 type/scope 保持英文（遵循 conventional commits 规范）。

4. 执行 Commit

简单变更（单文件、改动少）可用单行：

git commit -m "<type>[scope]: <中文描述>"

复杂变更（多文件、涉及逻辑或 UI）必须用多行，包含 body：

git commit -m "$(cat <<'EOF'
<type>[scope]: <中文描述>

- <文件A>: <具体改动1>
- <文件A>: <具体改动2>
- <文件B>: <具体改动3>
- <文件C>: <具体改动4>
EOF
)"

最佳实践

一个 commit 只做一件逻辑上完整的事
使用现在时："添加" 而非 "添加了"
使用祈使句："修复 bug" 而非 "修复了 bug"
关联 issue：Closes #123、Refs #456
描述控制在 72 字符以内
中文描述应简洁明确，避免冗余

Commit Message 质量示例

差的示例（过于笼统，没有信息量）：

feat: 优化组件

好的示例（具体到功能点和文件）：

feat(creative): 支持动态比例行布局并全面适配深色模式

- creative-grid.vue:
  - 新增 displayRatio 字段，区分布局比例与显示比例
  - 实现 canFitRatioItemsInRow 算法，根据图片比例动态决定每行显示数量
  - square 布局支持非 1:1 比例的媒体盒子，避免宽图被压缩为正方形
  - 修复失败/待处理资源导致整行被错误拆分为 square 的问题
- draw.vue:
  - 全局深色模式样式适配（背景、文字、边框统一使用 slate 色系）
  - 原图预览区域新增 +n 占位展示剩余省略图片
  - 视频创意编辑面板增加暗色边框和背景透明度
- BottomContent.vue:
  - 重构登录状态监听，拆分为两个独立 watch 避免重复触发过渡动画
- chatplus-form.vue: 移除 textarea 冗余边框样式，统一使用 focus ring

Git 安全协议

绝不修改 git config
绝不在未明确要求时执行破坏性命令（--force、hard reset 等）
绝不跳过 hooks（--no-verify），除非用户明确要求
绝不对 main/master 执行 force push
如果 commit 因 hook 失败，修复问题后创建新的 commit（不要 amend）