Commit
Un commit est la plus petite unité d'historique qu'une personne lira dans un an, sous pression, lors d'un incident. Optimisez pour ce lecteur.
Workflow
- Regardez avant de commiter :
git status,git diff --staged,git diff. Ne commitez jamais à l'aveugle. - Vérifiez tout ce qui ne doit pas atterrir : identifiants, fichiers
.env, clés privées, gros binaires, impressions de débogage, code commenté. Si trouvé, arrêtez-vous et informez l'utilisateur. Voir la compétencesecrets-hygiene. - Staging délibéré. Préférez
git add <paths>àgit add -A. Un seul changement logique par commit ; si le diff mélange un refactoring et une fonctionnalité, séparez-le. - Écrivez le message au format ci-dessous.
- Commitez avec un heredoc pour que les corps multi-lignes survivent au shell :
git commit -m "$(cat <<'MSG'
feat(auth): ajouter la connexion OIDC pour la console d'administration
Remplace le mot de passe partagé d'authentification de base par OIDC basé sur Cognito afin que l'accès puisse être révoqué par utilisateur. Les sessions expirent après 8h.
Refs: PLAT-412
MSG
)"
- Confirmez avec
git log -1 --stat. Ne jamais amender ou forcer le push sauf demande explicite de l'utilisateur.
Format du message
<type>(<scope>): <résumé impératif, ≤72 caractères, pas de point final>
<pourquoi ce changement existe, pas ce que le diff montre — le diff montre déjà cela>
<pied de page : Refs/Closes ticket, BREAKING CHANGE: ..., Co-Authored-By>
Types : feat, fix, refactor, perf, test, docs, build, ci, chore, revert.
Le scope est le module, le service ou la pile modifiée (api, terraform/vpc, ci). Omettez-le lorsque le changement est global.
Le corps est plus important que le résumé. Répondez « pourquoi maintenant ? » et « qu'avons-nous envisagé ? » en deux à quatre phrases. Un commit d'une ligne est acceptable pour des modifications triviales.
Exemples
Entrée : correction du pointeur nul lorsque le compartiment S3 n'a pas de balises
Sortie : fix(s3-inventory): gérer les compartiments sans ensemble de balises
Entrée : mise à jour du fournisseur Terraform AWS de 5.40 à 5.60, nécessaire pour le nouvel attribut runtime lambda Sortie :
build(terraform): mise à jour du fournisseur AWS vers 5.60
Nécessaire pour `aws_lambda_function.runtime = "python3.13"`. Aucun diff de ressource sur `terraform plan` dans toutes les piles.
Quand $ARGUMENTS est fourni
Traitez-le comme une indication de scope ou de résumé de la part de l'utilisateur, mais inspectez toujours le diff et corrigez-le s'il ne correspond pas à ce qui a réellement changé.