git-commit

name	git-commit
description	使用中文 Conventional Commit 提交代码。用户要求提交、commit、创建 git commit 或使用 /commit 时触发；先审查状态与 diff，区分本次任务改动和用户已有改动，只暂存相关文件，生成中文提交信息并执行 git commit。

Git Commit 中文提交助手

作用

当用户要求“提交一下”“commit”“创建 git commit”或使用 /commit 时，帮助完成一次安全、清晰、可追溯的 Git 提交。

核心目标：

• 只提交本次任务相关改动。
• 使用中文提交说明。
• 保留 Conventional Commits 的类型和作用域结构。
• 不覆盖、不回退、不混入用户已有改动。
• 提交失败时暴露真实错误并协助修复。

提交格式

优先使用单行中文 Conventional Commit：

<type>(<scope>): <中文描述>

示例：

fix(can): 修复 CAN7000 录波保存异常
docs(skills): 更新本地技能同步说明
chore(git): 调整提交助手规则

如果没有明确作用域，可以省略 scope：

docs: 更新技能列表

类型选择

类型	使用场景
feat	新增用户可见功能
fix	修复缺陷、异常行为或回归
docs	仅文档、说明、注释类改动
style	格式、空白、排版等不影响逻辑的改动
refactor	既非新增功能也非修复缺陷的代码重构
perf	性能优化
test	新增或调整测试
build	构建系统、依赖、工程配置
ci	CI/CD 配置
chore	维护性事务、脚本、工具配置
revert	回滚已有提交

工作流程

1. 检查仓库状态

先查看工作区状态和分支：

git status --short --branch

必须识别：

• 哪些文件是本次任务产生的。
• 哪些文件是用户原本已有的改动。
• 是否存在未跟踪文件、删除文件、子仓库改动或大范围无关变更。

如果工作区里有明显无关改动，不要全量暂存；只处理本次任务相关文件。

2. 分析 diff

如果已有暂存内容，优先分析暂存区：

git diff --staged

如果没有暂存内容，分析工作区改动：

git diff

需要判断：

• 改动目的是什么。
• 影响范围是什么。
• 是否应该拆成多个提交。
• 是否包含密钥、Token、私钥、.env、真实服务器密码等敏感信息。

3. 谨慎暂存

只暂存与本次提交直接相关的文件：

git add path/to/file1 path/to/file2

禁止为了省事执行无差别暂存：

git add .
git add -A

除非用户明确要求“提交全部改动”，否则不要使用全量暂存。

对于大型混合改动，优先建议拆分提交；如果必须从同一文件里挑选部分改动，可以使用交互式暂存：

git add -p

但在自动化环境中，优先采用明确文件路径暂存，避免进入交互式流程。

4. 生成中文提交信息

提交描述应满足：

• 使用中文。
• 简洁说明“做了什么”，不要写空泛词。
• 首行尽量不超过 72 个字符。
• 类型和作用域与实际 diff 对齐。
• 不夸大影响范围，不写未完成事项。

优先从文件路径、模块名、功能点推断 scope。例如：

• sync-agent-skills.ps1 -> skills
• embeddedskills/can/* -> can
• embeddedskills/gcc/* -> gcc
• normalskills/git-commit/* -> git

5. 执行提交

单行提交：

git commit -m "type(scope): 中文描述"

需要补充正文时，使用多条 -m：

git commit -m "type(scope): 中文描述" -m "补充说明改动背景、验证结果或兼容性影响。"

提交后读取结果，向用户说明：

• 提交 hash。
• 提交信息。
• 是否还有未提交改动。
• 是否有未纳入提交的用户改动。

多仓库规则

如果当前任务同时修改了多个独立 Git 仓库，应分仓提交。

每个仓库都要单独执行：

git status --short --branch
git diff
git add <相关文件>
git commit -m "type(scope): 中文描述"

不要跨仓库混淆提交结果。最终回复要分别列出每个仓库的提交 hash。

安全规则

• 不修改 Git 全局配置。
• 不执行 git reset --hard、git checkout -- <path> 等会丢弃改动的命令，除非用户明确要求。
• 不使用 --force、--force-with-lease 推送，除非用户明确要求。
• 不使用 --no-verify 跳过 hook，除非用户明确要求。
• 不 amend 已有提交，除非用户明确要求。
• 不提交密钥、Token、私钥、真实密码或本地敏感配置。
• 不为了让提交通过而删除测试、吞掉错误或隐藏失败信息。

失败处理

如果提交失败：

1. 保留真实错误输出。
2. 判断是 hook、格式检查、冲突、权限、路径编码还是 Git 状态问题。
3. 优先修复根因后重新提交。
4. 不要绕过校验，除非用户明确要求。

如果发现当前状态不适合提交，例如无关改动过多、敏感文件已暂存、仓库处于 rebase/merge 冲突中，应先停止并说明原因。