Notre avis

Effectue le stage et le commit des modifications en utilisant un format standardisé avec des préfixes de type.

Peut ne pas gérer les scénarios de branchement complexes
Dépend de la sortie git status qui peut être incomplète pour les fichiers non suivis
Commit sans confirmation, ce qui pourrait accidentellement inclure des modifications non liées

Quand l'utiliser

Utilisez-le lorsque vous devez effectuer un commit avec un message clair et standardisé suivant les conventions.

Quand l'éviter

Évitez-le lorsque vous devez rédiger un corps de message détaillé ou lorsque les modifications ne sont pas prêtes pour un commit unique cohérent.

name: commit description: Stage and commit changes with standardized format user-invocable: true disable-model-invocation: true

Standardized Commit

!git status --short

!git diff --stat

!git diff --cached --stat

Based on the git status and diff above:

Stage changes if not already staged:
- Stage relevant files (use judgment on what belongs together)
- Do not stage unrelated changes
- Do not stage files that likely contain secrets (.env, credentials, tokens)
Write commit message in this format:
```
<type>: <description>
```
Types:
- fix: Bug fix
- feat: New feature
- refactor: Code restructuring (no behavior change)
- docs: Documentation only
- test: Adding/updating tests
- chore: Build, config, tooling changes
Rules:
- Description is lowercase, no period at the end
- Keep under 72 characters total
- Be specific: not "fix bug" but "fix null pointer in request handler"
- Use imperative mood: "add feature" not "added feature"
Commit without asking for confirmation. Use a HEREDOC for the message:
```
git commit -m "$(cat <<'EOF'
<type>: <description>
EOF
)"
```

Good:

Bad: