Initial commit
This commit is contained in:
Zhongwei Li
196
git-commit/README.md
Normal file
196
git-commit/README.md
Normal file
@@ -0,0 +1,196 @@
|
||||
# Git Commit 技能
|
||||
|
||||
智能化的 Git 提交助手，帮助你快速完成代码审查、生成规范的提交信息并执行提交。
|
||||
|
||||
## 🚀 快速开始
|
||||
|
||||
### 基本使用
|
||||
|
||||
```
|
||||
你: "帮我提交这些代码"
|
||||
```
|
||||
|
||||
技能会自动：
|
||||
1. ✅ 检查暂存区状态
|
||||
2. 🔍 简单代码审查
|
||||
3. 📊 分析提交历史
|
||||
4. 📝 生成提交信息
|
||||
5. ✋ 等待你确认
|
||||
6. 🎉 执行提交
|
||||
|
||||
### 使用场景
|
||||
|
||||
#### 场景 1：暂存区已有文件
|
||||
```bash
|
||||
# 你已经执行了 git add
|
||||
git add src/main.rs src/config.rs
|
||||
|
||||
# 直接请求提交
|
||||
你: "提交代码"
|
||||
```
|
||||
|
||||
技能会直接使用暂存区的文件进行提交。
|
||||
|
||||
#### 场景 2：暂存区为空
|
||||
```
|
||||
你: "提交我的修改"
|
||||
```
|
||||
|
||||
技能会：
|
||||
1. 列出所有修改的文件
|
||||
2. 询问你要提交哪些文件
|
||||
3. 自动执行 `git add`
|
||||
4. 继续提交流程
|
||||
|
||||
#### 场景 3：审查并提交
|
||||
```
|
||||
你: "审查代码并提交"
|
||||
```
|
||||
|
||||
技能会进行简单的代码审查，检查：
|
||||
- 语法错误
|
||||
- 调试代码残留
|
||||
- 敏感信息泄露
|
||||
|
||||
## 📝 提交信息格式
|
||||
|
||||
### 自动识别项目规范
|
||||
|
||||
技能会从以下来源识别项目的提交规范：
|
||||
1. **Memory 中的项目规范**（优先级最高）
|
||||
2. **提交历史中的风格模式**
|
||||
3. **通用简洁格式**（默认）
|
||||
|
||||
### 配置项目规范
|
||||
|
||||
如果你的项目有特定的提交规范，可以在 Memory 中记录：
|
||||
|
||||
```
|
||||
你: "记录项目提交规范：使用 Conventional Commits 格式，type 包括 feat、fix、docs、refactor、test、chore"
|
||||
```
|
||||
|
||||
技能会自动保存到 Memory，后续提交时遵循该规范。
|
||||
|
||||
## 🎯 典型工作流
|
||||
|
||||
### 完整示例
|
||||
|
||||
```
|
||||
你: "提交代码"
|
||||
|
||||
技能:
|
||||
📊 检查到暂存区为空，发现以下修改：
|
||||
1. src/main.rs (修改)
|
||||
2. src/config.rs (修改)
|
||||
3. tests/test_config.rs (新增)
|
||||
4. README.md (修改)
|
||||
|
||||
请选择要提交的文件：
|
||||
[ ] 提交所有文件
|
||||
[ ] 选择特定文件
|
||||
[ ] 取消
|
||||
|
||||
你: "提交所有文件"
|
||||
|
||||
技能:
|
||||
✅ 已添加 4 个文件到暂存区
|
||||
|
||||
🔍 代码审查中...
|
||||
✅ 未发现明显问题
|
||||
|
||||
📊 变更摘要：
|
||||
- 修改文件：4 个
|
||||
- 新增行：+127
|
||||
- 删除行：-23
|
||||
|
||||
📝 提交信息：
|
||||
feat(config): 添加 TOML 配置支持
|
||||
|
||||
- 实现 TOML 配置读取
|
||||
- 添加配置文件解析
|
||||
- 更新测试用例
|
||||
- 完善文档说明
|
||||
|
||||
是否确认提交？
|
||||
|
||||
你: "确认"
|
||||
|
||||
技能:
|
||||
✅ 提交成功！
|
||||
commit: a1b2c3d feat(config): 添加 TOML 配置支持
|
||||
```
|
||||
|
||||
## ⚙️ 高级功能
|
||||
|
||||
### 历史分析
|
||||
|
||||
技能会分析最近 20 条提交记录，学习项目的提交风格：
|
||||
- 常用的 type 类型
|
||||
- scope 的命名习惯
|
||||
- 提交信息的语言（中文/英文）
|
||||
- 描述的详细程度
|
||||
|
||||
### 智能暂存区处理
|
||||
|
||||
- **暂存区非空**：直接使用，快速提交
|
||||
- **暂存区为空**：智能询问，避免误操作
|
||||
|
||||
### 提交前确认
|
||||
|
||||
每次提交前都会展示：
|
||||
- 变更文件列表和统计
|
||||
- 生成的提交信息
|
||||
- 代码审查结果
|
||||
|
||||
你可以：
|
||||
- 确认提交
|
||||
- 修改提交信息
|
||||
- 取消提交
|
||||
|
||||
## 🛠️ 配置示例
|
||||
|
||||
### Conventional Commits 规范
|
||||
|
||||
```
|
||||
你: "配置提交规范"
|
||||
|
||||
技能: "请描述你的提交规范"
|
||||
|
||||
你: "使用 Conventional Commits：
|
||||
- type: feat, fix, docs, refactor, test, chore
|
||||
- 格式: type(scope): subject
|
||||
- subject 使用中文
|
||||
- 可选的详细正文"
|
||||
|
||||
技能: "✅ 已保存到项目 Memory"
|
||||
```
|
||||
|
||||
### 自定义规范
|
||||
|
||||
```
|
||||
你: "我们团队的提交格式是：[模块名] 简短描述"
|
||||
|
||||
技能: "✅ 已记录，后续提交将遵循该格式"
|
||||
```
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### ✅ 推荐做法
|
||||
|
||||
1. **原子提交**：每次只提交一个逻辑变更
|
||||
2. **及时提交**：完成功能点后立即提交
|
||||
3. **清晰描述**：让他人快速理解变更目的
|
||||
4. **遵循规范**：保持项目风格一致
|
||||
|
||||
### ❌ 避免事项
|
||||
|
||||
1. **混合变更**：不要在一次提交中包含多个不相关修改
|
||||
2. **模糊描述**：避免 "update code"、"fix bug" 等无意义信息
|
||||
3. **跳过审查**：即使小改动也应快速检查
|
||||
4. **提交敏感信息**：检查是否包含密钥、令牌
|
||||
|
||||
## 🔗 相关资源
|
||||
|
||||
- 详细工作流程：查看 `SKILL.md`
|
||||
- 提交规范参考：查看 `REFERENCE.md`
|
||||
- [Conventional Commits 规范](https://www.conventionalcommits.org/)
|
||||
321
git-commit/REFERENCE.md
Normal file
321
git-commit/REFERENCE.md
Normal file
@@ -0,0 +1,321 @@
|
||||
# Git Commit 规范参考
|
||||
|
||||
本文档提供常见的提交信息规范、Memory 配置模板和常见问题解答。
|
||||
|
||||
## 📋 提交信息规范
|
||||
|
||||
### Conventional Commits
|
||||
|
||||
最流行的提交信息规范，广泛应用于开源项目。
|
||||
|
||||
#### 格式
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
|
||||
<body>
|
||||
|
||||
<footer>
|
||||
```
|
||||
|
||||
#### Type 类型
|
||||
| Type | 说明 | 示例 |
|
||||
|------|------|------|
|
||||
| `feat` | 新功能 | feat(auth): 添加用户登录功能 |
|
||||
| `fix` | 修复 bug | fix(api): 修复用户查询接口错误 |
|
||||
| `docs` | 文档更新 | docs(readme): 更新安装说明 |
|
||||
| `style` | 代码格式（不影响功能） | style(main): 统一代码缩进 |
|
||||
| `refactor` | 重构（不改变功能） | refactor(config): 简化配置加载逻辑 |
|
||||
| `perf` | 性能优化 | perf(query): 优化数据库查询性能 |
|
||||
| `test` | 测试相关 | test(user): 添加用户模块单元测试 |
|
||||
| `build` | 构建系统或依赖 | build(deps): 升级 tokio 到 1.35 |
|
||||
| `ci` | CI 配置 | ci(github): 添加自动发布工作流 |
|
||||
| `chore` | 其他杂项 | chore(release): 发布 v1.2.0 |
|
||||
| `revert` | 回滚提交 | revert: 回滚 feat(auth) 提交 |
|
||||
|
||||
#### Scope（可选）
|
||||
表示影响的模块或范围：
|
||||
- `api` - API 接口
|
||||
- `config` - 配置系统
|
||||
- `cli` - 命令行界面
|
||||
- `core` - 核心逻辑
|
||||
- `docs` - 文档
|
||||
- `test` - 测试
|
||||
|
||||
#### Subject
|
||||
- 使用祈使句，现在时态："添加"而非"添加了"
|
||||
- 首字母小写
|
||||
- 结尾不加句号
|
||||
- 简洁明了，不超过 50 字符
|
||||
|
||||
#### Body（可选）
|
||||
- 详细说明变更的原因和影响
|
||||
- 每行不超过 72 字符
|
||||
- 可以包含多个段落
|
||||
|
||||
#### Footer（可选）
|
||||
- Breaking Changes：`BREAKING CHANGE: 描述`
|
||||
- 关闭 Issue：`Closes #123, #456`
|
||||
- 引用相关 PR：`Refs #789`
|
||||
|
||||
#### 完整示例
|
||||
```
|
||||
feat(config): 添加 TOML 配置支持
|
||||
|
||||
实现了基于 TOML 格式的配置文件读取功能，替代原有的 JSON 格式。
|
||||
主要改进：
|
||||
- 更友好的配置语法
|
||||
- 支持注释
|
||||
- 更好的类型安全
|
||||
|
||||
BREAKING CHANGE: 配置文件格式从 JSON 改为 TOML
|
||||
Closes #42
|
||||
```
|
||||
|
||||
### Angular 规范
|
||||
|
||||
Angular 团队使用的提交规范，与 Conventional Commits 类似。
|
||||
|
||||
#### 格式
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
<BLANK LINE>
|
||||
<body>
|
||||
<BLANK LINE>
|
||||
<footer>
|
||||
```
|
||||
|
||||
#### Type 类型
|
||||
- `feat`: 新功能
|
||||
- `fix`: 修复
|
||||
- `docs`: 文档
|
||||
- `style`: 格式
|
||||
- `refactor`: 重构
|
||||
- `test`: 测试
|
||||
- `chore`: 构建/工具
|
||||
|
||||
#### 示例
|
||||
```
|
||||
fix(compiler): 修复模板解析错误
|
||||
|
||||
当模板包含特殊字符时，解析器会抛出异常。
|
||||
现在正确处理所有 Unicode 字符。
|
||||
|
||||
Fixes #1234
|
||||
```
|
||||
|
||||
### 简洁描述格式
|
||||
|
||||
适合小型项目或个人项目的简单格式。
|
||||
|
||||
#### 格式
|
||||
```
|
||||
简短描述（不超过 50 字符）
|
||||
|
||||
可选的详细说明
|
||||
```
|
||||
|
||||
#### 示例
|
||||
```
|
||||
添加用户认证功能
|
||||
|
||||
实现了基于 JWT 的用户认证系统
|
||||
```
|
||||
|
||||
### Gitmoji 规范
|
||||
|
||||
使用 emoji 表示提交类型，视觉化更强。
|
||||
|
||||
#### 常用 Emoji
|
||||
| Emoji | 代码 | 说明 |
|
||||
|-------|------|------|
|
||||
| ✨ | `:sparkles:` | 新功能 |
|
||||
| 🐛 | `:bug:` | 修复 bug |
|
||||
| 📝 | `:memo:` | 文档 |
|
||||
| 🎨 | `:art:` | 代码格式/结构 |
|
||||
| ⚡️ | `:zap:` | 性能优化 |
|
||||
| 🔥 | `:fire:` | 删除代码/文件 |
|
||||
| ✅ | `:white_check_mark:` | 测试 |
|
||||
| 🔒 | `:lock:` | 安全修复 |
|
||||
| ⬆️ | `:arrow_up:` | 升级依赖 |
|
||||
| ⬇️ | `:arrow_down:` | 降级依赖 |
|
||||
|
||||
#### 示例
|
||||
```
|
||||
✨ 添加用户登录功能
|
||||
🐛 修复配置文件解析错误
|
||||
📝 更新 API 文档
|
||||
```
|
||||
|
||||
## 🔧 Memory 配置模板
|
||||
|
||||
### Conventional Commits 配置
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "mcp__memory__create_entities",
|
||||
"parameters": {
|
||||
"entities": [{
|
||||
"name": "project:ccode:commit-convention",
|
||||
"entityType": "convention",
|
||||
"observations": [
|
||||
"使用 Conventional Commits 格式",
|
||||
"格式：<type>(<scope>): <subject>",
|
||||
"type 包括：feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert",
|
||||
"scope 为可选，表示影响的模块",
|
||||
"subject 使用中文，祈使句，首字母小写",
|
||||
"body 可选，详细说明变更原因",
|
||||
"footer 可选，包含 BREAKING CHANGE 或关闭的 Issue"
|
||||
]
|
||||
}]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 自定义规范配置
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "mcp__memory__create_entities",
|
||||
"parameters": {
|
||||
"entities": [{
|
||||
"name": "project:myproject:commit-convention",
|
||||
"entityType": "convention",
|
||||
"observations": [
|
||||
"格式：[模块名] 简短描述",
|
||||
"模块名使用大写，如：[API]、[UI]、[DB]",
|
||||
"描述使用中文，简洁明了",
|
||||
"示例：[API] 添加用户查询接口"
|
||||
]
|
||||
}]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 团队规范配置
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "mcp__memory__create_entities",
|
||||
"parameters": {
|
||||
"entities": [{
|
||||
"name": "project:teamproject:commit-convention",
|
||||
"entityType": "convention",
|
||||
"observations": [
|
||||
"使用 Jira 工单号开头",
|
||||
"格式：[PROJ-123] 描述",
|
||||
"描述使用英文，动词开头",
|
||||
"示例：[PROJ-123] Add user authentication",
|
||||
"必须关联 Jira 工单"
|
||||
]
|
||||
}]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## ❓ 常见问题
|
||||
|
||||
### Q1: 如何修改已生成的提交信息？
|
||||
|
||||
**A**: 在技能展示提交信息并询问确认时，你可以：
|
||||
```
|
||||
你: "修改提交信息为：fix(api): 修复用户查询接口超时问题"
|
||||
```
|
||||
|
||||
技能会使用你提供的信息进行提交。
|
||||
|
||||
### Q2: 如何跳过代码审查？
|
||||
|
||||
**A**: 技能默认进行简单审查。如果你确定代码没问题，可以：
|
||||
```
|
||||
你: "跳过审查，直接提交"
|
||||
```
|
||||
|
||||
### Q3: 如何提交部分文件？
|
||||
|
||||
**A**: 当暂存区为空时，技能会询问你选择文件。你也可以提前使用 `git add`：
|
||||
```bash
|
||||
git add src/main.rs src/config.rs
|
||||
```
|
||||
然后请求提交，技能会只提交这些文件。
|
||||
|
||||
### Q4: 提交信息太长怎么办？
|
||||
|
||||
**A**: 技能会自动将详细内容放到 body 部分：
|
||||
```
|
||||
feat(config): 添加 TOML 配置支持
|
||||
|
||||
- 实现 TOML 配置读取
|
||||
- 添加 .env 文件支持
|
||||
- 更新配置迁移逻辑
|
||||
- 完善测试用例
|
||||
```
|
||||
|
||||
### Q5: 如何处理 Breaking Changes？
|
||||
|
||||
**A**: 在 Memory 配置中说明，技能会识别重大变更并添加 footer：
|
||||
```
|
||||
feat(api): 重构用户认证接口
|
||||
|
||||
BREAKING CHANGE: 认证接口从 /auth 改为 /api/v2/auth
|
||||
```
|
||||
|
||||
### Q6: 提交失败怎么办？
|
||||
|
||||
**A**: 技能会显示错误信息。常见原因：
|
||||
- pre-commit hook 失败 → 修复代码质量问题
|
||||
- 提交信息格式不符 → 检查项目的 commitlint 配置
|
||||
- Git 配置问题 → 检查 user.name 和 user.email
|
||||
|
||||
### Q7: 如何查看提交历史？
|
||||
|
||||
**A**: 技能会自动分析最近 20 条提交。你也可以手动查看：
|
||||
```bash
|
||||
git log --oneline -20
|
||||
```
|
||||
|
||||
### Q8: 支持多语言提交信息吗？
|
||||
|
||||
**A**: 支持。技能会根据项目历史识别语言习惯：
|
||||
- 中文项目 → 生成中文提交信息
|
||||
- 英文项目 → 生成英文提交信息
|
||||
- 混合项目 → 遵循 Memory 中的配置
|
||||
|
||||
### Q9: 如何更新项目规范？
|
||||
|
||||
**A**: 使用 Memory 工具更新：
|
||||
```
|
||||
你: "更新提交规范：subject 改用英文"
|
||||
```
|
||||
|
||||
技能会更新 Memory 中的配置。
|
||||
|
||||
### Q10: 提交后发现错误怎么办？
|
||||
|
||||
**A**: 可以使用 `git commit --amend` 修改最后一次提交：
|
||||
```bash
|
||||
# 修改文件
|
||||
git add .
|
||||
git commit --amend
|
||||
```
|
||||
|
||||
或者创建新的修复提交：
|
||||
```
|
||||
你: "提交修复"
|
||||
```
|
||||
|
||||
## 📚 参考资源
|
||||
|
||||
### 官方文档
|
||||
- [Conventional Commits](https://www.conventionalcommits.org/)
|
||||
- [Angular Commit Guidelines](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)
|
||||
- [Gitmoji](https://gitmoji.dev/)
|
||||
|
||||
### 工具推荐
|
||||
- [commitlint](https://commitlint.js.org/) - 提交信息校验
|
||||
- [husky](https://typicode.github.io/husky/) - Git hooks 管理
|
||||
- [commitizen](https://commitizen-tools.github.io/commitizen/) - 交互式提交
|
||||
|
||||
### 最佳实践
|
||||
- [How to Write a Git Commit Message](https://cbea.ms/git-commit/)
|
||||
- [Git Commit Best Practices](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project)
|
||||
- [Semantic Versioning](https://semver.org/)
|
||||
314
git-commit/SKILL.md
Normal file
314
git-commit/SKILL.md
Normal file
@@ -0,0 +1,314 @@
|
||||
---
|
||||
name: git-commit
|
||||
description: 智能 Git 提交助手：审查代码变更、分析提交历史、生成符合项目规范的提交信息并执行提交。支持自定义规范、提交前确认和智能暂存区处理。
|
||||
---
|
||||
|
||||
# Git Commit 技能
|
||||
|
||||
智能化的 Git 提交工作流，集成代码审查、历史分析和规范化提交信息生成。
|
||||
|
||||
## 🎯 使用场景
|
||||
|
||||
### 触发条件
|
||||
- 用户明确请求创建 Git 提交
|
||||
- 关键词：`提交`、`commit`、`git commit`、`提交代码`
|
||||
- 用户完成代码修改后需要提交变更
|
||||
|
||||
### 典型示例
|
||||
```
|
||||
用户: "帮我提交这些代码"
|
||||
用户: "审查并提交当前的修改"
|
||||
用户: "创建一个 commit"
|
||||
用户: "把这些改动提交到 git"
|
||||
```
|
||||
|
||||
## 📋 工作流程
|
||||
|
||||
### 1. 检查暂存区状态
|
||||
```bash
|
||||
# 检查暂存区
|
||||
git status --porcelain
|
||||
git diff --cached --stat
|
||||
|
||||
# 如果暂存区为空，列出工作区文件
|
||||
git status --short
|
||||
git diff --name-status
|
||||
```
|
||||
|
||||
**决策逻辑**：
|
||||
- **暂存区非空** → 直接使用暂存区文件
|
||||
- **暂存区为空** → 列出工作区修改文件，询问用户确认提交范围
|
||||
|
||||
### 2. 用户确认（暂存区为空时）
|
||||
**列出工作区文件**：
|
||||
```bash
|
||||
# 获取所有修改、新增、删除的文件
|
||||
git status --short
|
||||
# 输出格式：
|
||||
# M src/main.rs (修改)
|
||||
# A src/config.rs (新增)
|
||||
# D old/legacy.rs (删除)
|
||||
# ?? untracked.txt (未跟踪)
|
||||
```
|
||||
|
||||
使用 `AskUserQuestion` 工具询问：
|
||||
- 提交所有修改的文件？
|
||||
- 提交特定文件？（展示上述文件清单供选择）
|
||||
- 取消提交？
|
||||
|
||||
根据用户选择执行 `git add` 操作。
|
||||
|
||||
### 3. 简单代码审查
|
||||
检查项：
|
||||
- 语法错误（通过 `cargo check`、`npm run lint` 等）
|
||||
- 明显的逻辑问题
|
||||
- 调试代码残留（console.log、println!、TODO 等）
|
||||
- 敏感信息泄露（密钥、令牌、凭证）
|
||||
|
||||
**不执行深度审查**（不调用 Codex MCP），保持快速反馈。
|
||||
|
||||
### 4. 分析提交历史
|
||||
```bash
|
||||
git log --oneline -10
|
||||
git log --format="%s" -20
|
||||
```
|
||||
|
||||
**分析目标**：
|
||||
- 识别项目的提交信息风格
|
||||
- 提取常用的 type 和 scope
|
||||
- 保持提交风格一致性
|
||||
|
||||
### 5. 读取项目提交规范
|
||||
从 Memory 中查找项目级提交规范：
|
||||
```
|
||||
# 使用项目级精确查询，避免跨项目污染
|
||||
mcp__memory__search_nodes(query: "project:<repo>:commit-convention")
|
||||
mcp__memory__open_nodes(names: ["project:<repo>:commit-convention"])
|
||||
```
|
||||
|
||||
**命名空间说明**：
|
||||
- `<repo>` 应替换为实际的仓库名称（如 `ccode`、`myproject`）
|
||||
- 使用 `project:` 前缀确保查询范围限定在当前项目
|
||||
- 避免使用模糊查询（如 `"commit convention"`），防止匹配到其他项目的规范
|
||||
|
||||
**规范来源优先级**：
|
||||
1. Memory 中的项目规范
|
||||
2. 提交历史中的风格模式
|
||||
3. 通用的简洁描述格式
|
||||
|
||||
### 6. 生成提交信息
|
||||
使用 `mcp__sequential-thinking__sequentialthinking` 分析变更并生成提交信息：
|
||||
|
||||
**思考步骤**（6-8 步）：
|
||||
1. 分析 `git diff --cached` 的变更内容
|
||||
2. 识别变更的主要目的（新功能、修复、重构等）
|
||||
3. 提取关键的文件和模块
|
||||
4. 匹配项目提交规范格式
|
||||
5. 生成简洁准确的提交信息
|
||||
6. 验证提交信息是否符合规范
|
||||
|
||||
**提交信息格式**（根据项目规范）：
|
||||
- 自定义规范：遵循 Memory 中的定义
|
||||
- 无规范时：`<type>: <简洁描述>`
|
||||
|
||||
### 7. 展示变更摘要和提交信息
|
||||
向用户展示：
|
||||
```
|
||||
📊 变更摘要：
|
||||
- 修改文件：3 个
|
||||
- 新增行：+45
|
||||
- 删除行：-12
|
||||
|
||||
📝 提交信息：
|
||||
feat(config): 添加 TOML 配置支持
|
||||
|
||||
- 实现 TOML 配置读取
|
||||
- 添加 .env 文件支持
|
||||
- 更新配置迁移逻辑
|
||||
|
||||
✅ 代码审查：通过（无明显问题）
|
||||
|
||||
是否确认提交？
|
||||
```
|
||||
|
||||
### 8. 执行提交
|
||||
用户确认后执行：
|
||||
```bash
|
||||
git commit -m "$(cat <<'EOF'
|
||||
<提交信息>
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
验证提交成功：
|
||||
```bash
|
||||
git log -1 --oneline
|
||||
```
|
||||
|
||||
## 🔧 MCP 工具调用
|
||||
|
||||
### Memory 工具
|
||||
```json
|
||||
{
|
||||
"name": "mcp__memory__search_nodes",
|
||||
"parameters": {
|
||||
"query": "project:<repo>:commit-convention"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "mcp__memory__open_nodes",
|
||||
"parameters": {
|
||||
"names": ["project:<repo>:commit-convention"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**注意**：`<repo>` 应替换为实际仓库名，如 `project:ccode:commit-convention`
|
||||
|
||||
### Sequential Thinking 工具
|
||||
```json
|
||||
{
|
||||
"name": "mcp__sequential-thinking__sequentialthinking",
|
||||
"parameters": {
|
||||
"thought": "分析 git diff 变更内容...",
|
||||
"thoughtNumber": 1,
|
||||
"totalThoughts": 6,
|
||||
"nextThoughtNeeded": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 📝 协作模板
|
||||
|
||||
### 标准提交流程
|
||||
```markdown
|
||||
1. 检查暂存区状态（git status --porcelain, git diff --cached --stat）
|
||||
2. 如果暂存区为空：
|
||||
- 使用 git status --short 列出所有工作区修改文件
|
||||
- 询问用户选择提交范围（全部/特定文件/取消）
|
||||
- 根据选择执行 git add
|
||||
3. 简单代码审查（语法、明显问题）
|
||||
4. 分析最近 20 条提交历史（git log --format="%s" -20）
|
||||
5. 从 Memory 读取项目提交规范（使用 project:<repo>:commit-convention 精确查询）
|
||||
6. 使用 Sequential Thinking 生成提交信息
|
||||
7. 展示变更摘要和提交信息
|
||||
8. 等待用户确认
|
||||
9. 执行 git commit
|
||||
10. 验证提交成功（git log -1 --oneline）
|
||||
```
|
||||
|
||||
### 提交信息生成模板
|
||||
```markdown
|
||||
根据以下信息生成提交信息：
|
||||
|
||||
**变更内容**：
|
||||
<git diff --cached 输出>
|
||||
|
||||
**项目规范**：
|
||||
<Memory 中的规范或历史风格>
|
||||
|
||||
**要求**：
|
||||
- 简洁准确，一行概括主要变更
|
||||
- 如有多个变更，在正文中分点说明
|
||||
- 遵循项目规范格式
|
||||
- 避免技术细节，关注变更目的
|
||||
```
|
||||
|
||||
## ⚙️ 配置项目提交规范
|
||||
|
||||
### 在 Memory 中记录规范
|
||||
```json
|
||||
{
|
||||
"name": "mcp__memory__create_entities",
|
||||
"parameters": {
|
||||
"entities": [{
|
||||
"name": "project:<repo>:commit-convention",
|
||||
"entityType": "convention",
|
||||
"observations": [
|
||||
"使用 Conventional Commits 格式：<type>(<scope>): <subject>",
|
||||
"常用 type：feat, fix, docs, refactor, test, chore",
|
||||
"scope 为可选，表示影响的模块",
|
||||
"subject 使用中文，简洁描述变更",
|
||||
"正文可选，详细说明变更原因和影响"
|
||||
]
|
||||
}]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**命名规范**：
|
||||
- 实体名称格式：`project:<repo>:commit-convention`
|
||||
- `<repo>` 替换为实际仓库名（如 `ccode`、`myproject`）
|
||||
- 使用 kebab-case 命名风格
|
||||
- 确保命名空间隔离，避免跨项目污染
|
||||
|
||||
### 示例规范
|
||||
```
|
||||
type(scope): subject
|
||||
|
||||
body (可选)
|
||||
|
||||
footer (可选)
|
||||
```
|
||||
|
||||
**type 类型**：
|
||||
- `feat`: 新功能
|
||||
- `fix`: 修复 bug
|
||||
- `docs`: 文档更新
|
||||
- `refactor`: 重构
|
||||
- `test`: 测试相关
|
||||
- `chore`: 构建/工具/依赖更新
|
||||
|
||||
## ✅ 最佳实践
|
||||
|
||||
### 推荐做法
|
||||
1. **提交前审查**：始终检查 `git diff` 确认变更内容
|
||||
2. **原子提交**：每次提交只包含一个逻辑变更
|
||||
3. **清晰描述**：提交信息应让他人快速理解变更目的
|
||||
4. **遵循规范**：保持项目提交风格一致
|
||||
5. **及时提交**：完成一个功能点后立即提交
|
||||
|
||||
### 避免事项
|
||||
1. **混合变更**：不要在一次提交中包含多个不相关的修改
|
||||
2. **模糊描述**：避免 "update code"、"fix bug" 等无意义信息
|
||||
3. **提交敏感信息**：检查是否包含密钥、令牌等
|
||||
4. **跳过审查**：即使是小改动也应快速检查
|
||||
5. **忽略规范**：不要随意偏离项目约定的格式
|
||||
|
||||
## 🚨 错误处理
|
||||
|
||||
### 暂存区为空且用户取消
|
||||
```
|
||||
暂存区为空，需要先添加文件。
|
||||
已取消提交操作。
|
||||
```
|
||||
|
||||
### 代码审查发现问题
|
||||
```
|
||||
⚠️ 代码审查发现以下问题：
|
||||
- src/main.rs:42: 包含 println! 调试代码
|
||||
- config/.env: 可能包含敏感信息
|
||||
|
||||
建议修复后再提交。是否继续？
|
||||
```
|
||||
|
||||
### 提交失败
|
||||
```
|
||||
❌ 提交失败：<错误信息>
|
||||
|
||||
可能原因：
|
||||
- pre-commit hook 失败
|
||||
- 提交信息格式不符合要求
|
||||
- Git 配置问题
|
||||
|
||||
请检查错误信息并重试。
|
||||
```
|
||||
|
||||
## 📚 相关资源
|
||||
|
||||
- [Conventional Commits 规范](https://www.conventionalcommits.org/)
|
||||
- [Git 提交最佳实践](https://git-scm.com/book/zh/v2)
|
||||
- [如何编写 Git 提交信息](https://cbea.ms/git-commit/)
|
||||
Reference in New Issue
Block a user