Filename
group-and-commit-changes.md
Content
# Group and Commit Changes
## Objective
Analyze all staged and unstaged changes in a git repository, intelligently group related modifications, generate conventional commit messages, and execute commits with user approval.
## Workflow
### 1. Change Discovery
- Run `git status` to identify all modified, added, and deleted files
- Use `git diff` for unstaged changes and `git diff --staged` for staged changes
- For each changed file, analyze the diff to understand:
- Type of change (feature, fix, refactor, docs, style, test, chore)
- Scope of change (which component/module)
- Breaking changes (if any)
### 2. Intelligent Grouping
Group changes based on these criteria (in priority order):
**Primary groupings:**
- **Feature additions** - New functionality or capabilities
- **Bug fixes** - Corrections to existing functionality
- **Refactoring** - Code restructuring without behavior changes
- **Documentation** - README, comments, docs updates
- **Tests** - New or updated test files
- **Dependencies** - Package.json, requirements.txt, etc.
- **Configuration** - Config files, environment settings
- **Styling/Formatting** - Linting, prettier, whitespace changes
- **Build/CI** - Build scripts, CI/CD configuration
- **Chores** - Routine tasks, maintenance
**Avoid:**
- Mixing unrelated changes in one commit
- Creating commits with mixed types (e.g., features + formatting)
- Grouping changes that span multiple unrelated features
### 3. Commit Message Generation
Use **Conventional Commits** format:
"""
<type>(<scope>): <description>
[optional body]
"""
**Types:**
- `feat`: New feature
- `fix`: Bug fix
- `docs`: Documentation only
- `style`: Formatting, missing semicolons, etc. (no code change)
- `refactor`: Code change that neither fixes a bug nor adds a feature
- `perf`: Performance improvement
- `test`: Adding or updating tests
- `deps`: Dependencies
- `build`: Build system
- `ci`: CI configuration changes
- `chore`: Other changes that don't modify src or test files
**Best practices:**
- Avoid emojis
- Keep the description under 50 characters
- Use imperative mood ("add" not "added" or "adds")
- Don't end subject line with a period
- Separate subject from body with a blank line
- Body should explain what and why, not how
- Don't capitalize the first letter of the description
## Edge Cases
- **No changes detected**: Inform user, exit gracefully
- **Merge conflicts**: Warn user, suggest resolving before committing
- **Large commits**: Warn if a single commit exceeds 500 lines, suggest splitting
- **Uncommitted changes + staged changes**: Handle both, keep separate
- **Binary files**: Note but don't show diffs, group appropriately
- **Breaking changes**: Add `BREAKING CHANGE:` in commit footer
## Additional Features
- **Interactive mode**: Allow user to reclassify files during review
- **Commit history context**: Check recent commits to maintain consistency
- **Atomic commits**: Ensure each commit is self-contained and buildable
- **Dry run option**: Show what would be committed without executing
## Constraints
- Respect .gitignore rules
- Maintain chronological logic (dependencies before features)
Useful links