micro-commit
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseThis approach is inspired by Lucas Rocha's micro-commit methodology, which emphasizes breaking down changes into small, logical, and independently meaningful commits.
这种方法灵感来自Lucas Rocha的微提交方法论,该方法强调将变更分解为小型、逻辑独立且有意义的提交。
Core Guidelines
核心准则
Before starting any task, read and follow
/key-guidelinesCommits unstaged changes by grouping them into logical micro-commits using the git-operations-specialist skill.
在开始任何任务前,请阅读并遵循
/key-guidelines借助git-operations-specialist技能,将未暂存的变更按逻辑分组,创建微提交。
Dependencies
依赖项
- use git-operations-specialist skill
- 使用git-operations-specialist技能
Instructions
操作说明
IMPORTANT: Use the git-operations-specialist skill (via Skill tool) for ALL git-related operations in this command.
Analyze all unstaged changes and execute multiple micro-commits, grouping related changes together.
重要提示:执行此命令中的所有Git相关操作时,请使用git-operations-specialist技能(通过Skill工具)。
分析所有未暂存的变更,并执行多次微提交,将相关变更归为一组。
Required Execution Items
必执行项
-
Check Current Status: Runto identify all unstaged changes
git status -
Group Changes by Context: Analyze the changes and group them logically:
- By File Type: Group similar file types (e.g., all TypeScript files, all config files)
- By Feature: Group files that implement the same feature
- By Layer: Group by architectural layer (e.g., API changes, frontend changes, database changes)
- By Purpose: Group by purpose (e.g., new features, bug fixes, refactoring, configuration)
-
Create Micro-Commits: For each logical group:
- Stage only the files in that group using
git add - Create a focused commit with a clear message
- Verify the commit was successful
- Stage only the files in that group using
-
Commit Message Guidelines:
- Follow the template format
.gitmessage - Use appropriate commit type prefixes: ,
feat,fix,refactor,docs,style,testchore - Each commit should describe ONE logical change
- Follow the
-
Final Verification: After all commits, runto confirm no changes remain unstaged
git status
-
检查当前状态:运行识别所有未暂存的变更
git status -
按上下文分组变更:分析变更并进行逻辑分组:
- 按文件类型:将相似类型的文件分组(例如,所有TypeScript文件、所有配置文件)
- 按功能:将实现同一功能的文件分组
- 按架构层:按架构层分组(例如,API变更、前端变更、数据库变更)
- 按用途:按用途分组(例如,新功能、Bug修复、重构、配置调整)
-
创建微提交:针对每个逻辑分组:
- 使用仅暂存该分组中的文件
git add - 创建一条清晰的提交信息,完成聚焦式提交
- 验证提交是否成功
- 使用
-
提交信息准则:
- 遵循模板格式
.gitmessage - 使用合适的提交类型前缀:、
feat、fix、refactor、docs、style、testchore - 每个提交应描述一项逻辑变更
- 遵循
-
最终验证:完成所有提交后,运行确认没有剩余未暂存的变更
git status
⚠️ Important Constraints
⚠️ 重要约束
- Stage files explicitly - Use for each group before committing
git add <file> - Use HEREDOC - Maintain proper formatting of commit messages
- One Context Per Commit - Each commit should represent a single logical change
- Sequential Processing - Process one group at a time, verifying each commit before moving to the next
- 显式暂存文件 - 提交前使用为每个分组暂存文件
git add <file> - 使用HEREDOC - 保持提交信息的正确格式
- 一提交一上下文 - 每个提交应代表单一逻辑变更
- 顺序处理 - 一次处理一个分组,验证提交成功后再处理下一个
Example Grouping Strategy
分组策略示例
If you have changes to:
- (API logic)
apps/api/src/routes/timeline.ts - (Type definitions)
apps/dashboard/src/types/api.ts - (UI component)
apps/dashboard/src/components/TimelineVisjs.tsx - (Configuration)
apps/api/tsconfig.json
Group them as:
- Commit 1: API logic changes ()
apps/api/src/routes/timeline.ts - Commit 2: Type definitions ()
apps/dashboard/src/types/api.ts - Commit 3: UI component changes ()
apps/dashboard/src/components/TimelineVisjs.tsx - Commit 4: Configuration changes ()
apps/api/tsconfig.json
如果你有以下文件的变更:
- (API逻辑)
apps/api/src/routes/timeline.ts - (类型定义)
apps/dashboard/src/types/api.ts - (UI组件)
apps/dashboard/src/components/TimelineVisjs.tsx - (配置文件)
apps/api/tsconfig.json
分组方式如下:
- 提交1:API逻辑变更()
apps/api/src/routes/timeline.ts - 提交2:类型定义变更()
apps/dashboard/src/types/api.ts - 提交3:UI组件变更()
apps/dashboard/src/components/TimelineVisjs.tsx - 提交4:配置变更()
apps/api/tsconfig.json