Git Commit avec Conventional Commits
Aperçu
Créez des commits git standardisés et sémantiques à l'aide de la spécification Conventional Commits. Analysez le diff réel pour déterminer le type, le scope et le message appropriés.
Format Conventional Commit
<type>[scope optionnel]: <description>
[corps optionnel]
[pied(s) de page optionnel(s)]
Types de Commit
| Type | Objectif |
|---|---|
feat | Nouvelle fonctionnalité |
fix | Correction de bug |
docs | Documentation uniquement |
style | Mise en forme/style (pas de logique) |
refactor | Refactorisation du code (pas de fonctionnalité/correction) |
perf | Amélioration de performance |
test | Ajout/mise à jour de tests |
build | Système de build/dépendances |
ci | Modifications CI/config |
chore | Maintenance/divers |
revert | Annulation de commit |
Changements Casseurs (Breaking Changes)
# Point d'exclamation après le type/scope
feat!: supprimer l'API dépréciée
# Pied de page BREAKING CHANGE
feat: permettre à la configuration d'étendre d'autres configurations
BREAKING CHANGE: le comportement de la clé `extends` a changé
Flux de Travail
1. Analyser le Diff
# Si les fichiers sont en stage, utiliser le diff stagé
git diff --staged
# Si rien n'est en stage, utiliser le diff de l'arbre de travail
git diff
# Vérifier aussi l'état
git status --porcelain
2. Mettre en Stage les Fichiers (si nécessaire)
Si rien n'est en stage ou si vous souhaitez regrouper les modifications différemment :
# Mettre en stage des fichiers spécifiques
git add chemin/vers/fichier1 chemin/vers/fichier2
# Mettre en stage par motif
git add *.test.*
git add src/composants/*
# Mise en stage interactive
git add -p
Ne jamais committer de secrets (.env, credentials.json, clés privées).
3. Générer le Message de Commit
Les messages de commit DOIVENT être rédigés strictement et uniquement en anglais — tant le sujet que le corps. N'écrivez jamais un message de commit en russe, même si l'historique du dépôt contient des commits en russe.
Analysez le diff pour déterminer :
- Type : Quel type de changement est-ce ?
- Scope : Quelle zone/module est affecté(e) ?
- Description : Résumé en une ligne de ce qui a changé (présent, impératif, <72 caractères)
4. Exécuter le Commit
# Ligne unique
git commit -m "<type>[scope]: <description>"
# Multi-ligne avec corps/pied de page
git commit -m "$(cat <<'EOF'
<type>[scope]: <description>
<corps optionnel>
<pied de page optionnel>
EOF
)"
Bonnes Pratiques
- Rédigez les messages de commit strictement en anglais uniquement (sujet et corps)
- Un changement logique par commit
- Présent : "add" pas "added"
- Impératif : "fix bug" pas "fixes bug"
- Référencez des tickets :
Closes #123,Refs #456 - Gardez la description sous 72 caractères
Protocole de Sécurité Git
- NE JAMAIS mettre à jour la config git
- NE JAMAIS exécuter de commandes destructrices (--force, hard reset) sans demande explicite
- NE JAMAIS ignorer les hooks (--no-verify) sauf si l'utilisateur le demande
- NE JAMAIS forcer le push vers main/master
- Si le commit échoue à cause des hooks, corrigez et créez un NOUVEAU commit (ne faites pas d'amend)
- NE JAMAIS créer une nouvelle branche sans demander explicitement à l'utilisateur au préalable.
Commitez directement sur la branche actuelle (y compris
main) sauf si l'utilisateur a demandé une branche. Ne créez PAS automatiquement de branche "pour la sécurité" — l'utilisateur gère le branching. Si vous pensez qu'une branche est justifiée, DEMANDEZ avant d'en créer une. - NE JAMAIS pousser vers une nouvelle branche distante ni ouvrir un MR/PR sauf si l'utilisateur le demande.