Commits.mdc

description: This rules needs to apply when commiting to git. alwaysApply: false

Pre-Commit Workflow

1. Check Current Status

Before creating commits, always review your current changes:

# Check which files have been modified
git status

# See detailed changes in all modified files
git diff

# See changes in specific files
git diff <filename>

# See staged vs unstaged changes
git diff --cached  # Shows staged changes
git diff HEAD      # Shows all changes (staged + unstaged)

2. Review and Analyze Changes

Identify what functionality was added, modified, or removed
Group related changes by:
- Feature additions
- Bug fixes
- Refactoring
- Documentation updates
- Configuration changes
- Test modifications

3. Stage Changes Strategically

Instead of

git add .

, stage files selectively:

# Stage specific files
git add <file1> <file2>

# Stage parts of files interactively
git add -p <filename>

# Stage all files of a certain type
git add *.py
git add *.md

# Review what's staged
git diff --cached

Logical Commit Grouping

Group Changes By:

Feature Scope: Each new feature should be its own commit
Bug Fixes: Each bug fix should be separate
Refactoring: Code improvements without functional changes
Documentation: README, comments, or doc updates
Configuration: Settings, dependencies, or build changes
Tests: New tests or test modifications

Example Workflow:

# 1. Check what changed
git status
git diff

# 2. If you have mixed changes, create separate commits:

# Commit 1: Fix a specific bug
git add src/bug-file.py tests/test-bug-fix.py
git commit -m "fix(api): resolve timeout issue in user endpoint"

# Commit 2: Add new feature
git add src/feature-file.py src/feature-helper.py
git commit -m "feat(auth): add two-factor authentication"

# Commit 3: Update documentation
git add README.md docs/api.md
git commit -m "docs: update authentication setup guide"

# Commit 4: Refactor existing code
git add src/utils.py
git commit -m "refactor(utils): simplify date formatting functions"

Conventional Commits Rule

Always follow the Conventional Commits specification for all commit messages.

Commit Message Format

<type>[scope]: <description>

[optional body]

[optional footer(s)]

Commit Types

feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing tests or correcting existing tests
build: Changes that affect the build system or external dependencies
ci: Changes to CI configuration files and scripts
chore: Other changes that don't modify src or test files
revert: Reverts a previous commit

Scope

Use only one of these scopes. Do not invent other scopes (e.g. no

adaptive-testing

api

auth

backend: Changes to the backend code (apps/backend/)
frontend: Changes to the frontend code (apps/frontend/)
sdk: Changes to the SDK code (sdk/)
tests: Changes to the test code (tests/)
dev: Changes to the development tools and configuration e.g. Makefile, .env files, etc.

Rules

Use lowercase for type and description
No period at the end of the description
Use imperative mood in the description (e.g., "add" not "adds" or "added")
Limit the description to 50 characters or less
Use scope to specify the component/module affected (e.g.,
```
feat(backend): add login validation
```
)
Add body and footer if needed for breaking changes or additional context
Use
```
BREAKING CHANGE:
```
in footer for breaking changes

Examples

```
feat(backend): add user authentication
```

fix(frontend): resolve timeout issue in user endpoint

```
docs: update installation guide
```

refactor(backend): simplify date formatting function

```
feat!: remove deprecated API endpoints
```
(! indicates breaking change)

Advanced Git Commands for Commit Management

Splitting Large Changes

# If you have too many changes in one file, split them:
git add -p <filename>  # Interactively stage hunks

# Reset specific files from staging
git reset <filename>

# Reset specific hunks
git reset -p <filename>

Amending and Fixing Commits

# Add more changes to the last commit
git add <forgotten-file>
git commit --amend

# Change the last commit message
git commit --amend -m "new commit message"

# Interactive rebase to reorganize recent commits
git rebase -i HEAD~3  # Edit last 3 commits

Best Practices

Atomic Commits: Each commit should represent one logical change
Frequent Commits: Commit early and often, but keep commits meaningful
Clear History: Your commit history should tell a story of your project's evolution
Review Before Push: Always review your commits before pushing
Test Each Commit: Ideally, each commit should leave the codebase in a working state

Quick Checklist Before Committing

Run
```
git status
```
to see what's changed
Run
```
git diff
```
to review the actual changes
Group related changes together
Write descriptive commit messages following conventional commits
Test that each commit doesn't break functionality
Consider if any commit needs a longer description or breaking change notice

When creating commits, always format them according to this specification and follow the logical grouping workflow.