Git Conventions — Guide automatique

Ce skill s'active quand des opérations git sont effectuées en dehors de la commande /push.

Conventional Commits

Format : type(scope): description

Types

Type	Quand
`feat`	Nouvelle fonctionnalité
`fix`	Correction de bug
`refactor`	Restructuration sans changement de comportement
`docs`	Documentation uniquement
`test`	Ajout ou modification de tests
`chore`	Maintenance, config, CI
`style`	Formatage, espaces, points-virgules
`perf`	Amélioration de performance

Règles de message

•Impératif : "add feature" pas "added feature"
•Minuscule : pas de majuscule après le type
•Court : max 72 caractères pour la première ligne
•Descriptif : expliquer le "pourquoi" dans le body si nécessaire
•Scope : optionnel, indique le module/composant concerné

Exemples

code

feat(auth): add JWT token refresh
fix(api): handle timeout on slow connections
refactor: extract validation logic into helpers
docs: update API endpoints in README

Nommage de branches

Format : type/description-courte

code

feature/user-auth
fix/login-timeout
chore/update-deps
refactor/api-structure

Garde-fous

Avant chaque commit

•.gitignore vérifié — pas de .env, secrets, node_modules, fichiers temp
•Pas de clés API, tokens, mots de passe dans le code
•Pas de fichiers binaires volumineux
•git diff --cached relu pour vérifier ce qui part

Opérations dangereuses — TOUJOURS demander

•git push --force → Jamais sur main/master sans validation
•git reset --hard → Perte de travail potentielle
•git branch -D → Suppression irréversible
•git rebase sur branche partagée → Risque de conflit pour l'équipe

En cas de conflit

•Investiguer avant de résoudre — comprendre les deux côtés
•Ne jamais écraser silencieusement les changements de l'autre
•En doute → demander à l'utilisateur

Message de PR

markdown

## Summary
- [changements principaux en 1-3 bullets]

## Test plan
- [ ] [ce qui a été vérifié]

Code Review via PR

Quand on review ou crée une PR, vérifier :

Avant de créer la PR

•Titre court et descriptif (max 70 caractères)
•Description avec contexte (pourquoi, pas juste quoi)
•Une PR = un sujet (pas de "fix bug + add feature + update deps")
•Pas de fichiers hors périmètre (console.log, formatting, imports non utilisés)

Quand on review

•Comprendre le contexte avant de commenter
•Critique le code, pas la personne
•Distinguer bloquant (bug, sécu) vs suggestion (style, perf)
•Proposer une alternative concrète, pas juste "c'est pas bien"
•Valider les tests et le build avant d'approuver