git-commit

# Git Commit 中文提交助手 ## 作用 当用户要求“提交一下”“commit”“创建 git commit”或使用 `/commit` 时，帮助完成一次安全、清晰、可追溯的 Git 提交。 核心目标： - 只提交本次任务相关改动。 - 使用中文提交说明。 - 保留 Conventional Commits 的类型和作用域结构。 - 不覆盖、不回退、不混入用户已有改动。 - 提交失败时暴露真实错误并协助修复。 ## 提交格式 优先使用单行中文 Conventional Commit： ```text <type>(<scope>): <中文描述> ``` 示例： ```text fix(can): 修复 CAN7000 录波保存异常 docs(skills): 更新本地技能同步说明 chore(git): 调整提交助手规则 ``` 如果没有明确作用域，可以省略 `scope`： ```text docs: 更新技能列表 ``` ## 类型选择 | 类型 | 使用场景 | | --- | --- | | `feat` | 新增用户可见功能 | | `fix` | 修复缺陷、异常行为或回归 | | `docs` | 仅文档、说明、注释类改动 | | `style` | 格式、空白、排版等不影响逻辑的改动 | | `refactor` | 既非新增功能也非修复缺陷的代码重构 | | `perf` | 性能优化 | | `test` | 新增或调整测试 | | `build` | 构建系统、依赖、工程配置 | | `ci` | CI/CD 配置 | | `chore` | 维护性事务、脚本、工具配置 | | `revert` | 回滚已有提交 | ## 工作流程 ### 1. 检查仓库状态 先查看工作区状态和分支： ```bash git status --short --branch ``` 必须识别： - 哪些文件是本次任务产生的。 - 哪些文件是用户原本已有的改动。 - 是否存在未跟踪文件、删除文件、子仓库改动或大范围无关变更。 如果工作区里有明显无关改动，不要全量暂存；只处理本次任务相关文件。 ### 2. 分析 diff 如果已有暂存内容，优先分析暂存区： ```bash git diff --staged ``` 如果没有暂存内容，分析工作区改动： ```bash git diff ``` 需要判断： - 改动目的是什么。 - 影响范围是什么。 - 是否应该拆成多个提交。 - 是否包含密钥、Token、私钥、`.env`、真实服务器密码等敏感信息。 ### 3. 谨慎暂存 只暂存与本次提交直接相关的文件： ```bash git add path/to/file1 path/to/file2 ``` 禁止为了省事执行无差别暂存： ```bash git add . git add -A ``` 除非用户明确要求“提交全部改动”，否则不要使用全量暂存。 对于大型混合改动，优先建议拆分提交；如果必须从同一文件里挑选部分改动，可以使用交互式暂存： ```bash git add -p ``` 但在自动化环境中，优先采用明确文件路径暂存，避免进入交互式流程。 ### 4. 生成中文提交信息 提交描述应满足： - 使用中文。 - 简洁说明“做了什么”，不要写空泛词。 - 首行尽量不超过 72 个字符。 - 类型和作用域与实际 diff 对齐。 - 不夸大影响范围，不写未完成事项。 优先从文件路径、模块名、功能点推断 `scope`。例如： - `sync-agent-skills.ps1` -> `skills` - `embeddedskills/can/*` -> `can` - `embeddedskills/gcc/*` -> `gcc` - `normalskills/git-commit/*` -> `git` ### 5. 执行提交 单行提交： ```bash git commit -m "type(scope): 中文描述" ``` 需要补充正文时，使用多条 `-m`： ```bash git commit -m "type(scope): 中文描述" -m "补充说明改动背景、验证结果或兼容性影响。" ``` 提交后读取结果，向用户说明： - 提交 hash。 - 提交信息。 - 是否还有未提交改动。 - 是否有未纳入提交的用户改动。 ## 多仓库规则 如果当前任务同时修改了多个独立 Git 仓库，应分仓提交。 每个仓库都要单独执行： ```bash 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 冲突中，应先停止并说明原因。