Git Conventions

---
name: git-conventions
description: "Conventional commits et garde-fous git. Se charge sur : git commit, git push, git branch, git checkout -b, git merge, git rebase, git reset, git pull, git cherry-pick, git revert, création de PR (gh pr create), édition de message de commit. Couvre : messages conventional (feat:, fix:, refactor:, docs:, chore:, test:, style:, perf:, build:, ci:), nommage de branches (feat/*, fix/*, chore/*), messages et descriptions de PR, garde-fous destructifs (force push, reset --hard, branch -D, clean -f, push --force). Hors /codebloom:push qui gère son propre flow. Ne se charge PAS quand : opération git en lecture seule (git status, git log, git diff, git show, git blame)."
allowed-tools: "Bash(git:*) Read"
---

# Git Conventions — Guide automatique

Ce skill s'active quand des opérations git sont effectuées en dehors de la commande `/codebloom: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

```
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`

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

## Granularité des commits

- **Un commit = un changement logique** — pas un dump de fin de journée
- Séparer refactoring et feature dans des commits distincts
- Si le message nécessite "et" → probablement 2 commits
- Commit fréquent en local, squash si nécessaire avant merge

```
# MAL — un dump de fin de journée
git commit -m "fix login, add dashboard, update deps, refactor utils"

# BIEN — un commit par changement logique
git commit -m "fix(auth): handle expired JWT on refresh"
git commit -m "feat(dashboard): add weekly stats chart"
git commit -m "chore: update axios to 1.7.0"
```

## 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 — demander avant d'exécuter

> Sample prompt Anthropic ([prompting best practices — Balancing autonomy and safety](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices#balancing-autonomy-and-safety)) : *Consider the reversibility and potential impact of your actions. Local, reversible actions like editing files or running tests are fine, but for actions that are hard to reverse, affect shared systems, or could be destructive, ask the user before proceeding.*

Trois catégories à reconnaître. Toujours confirmer avec l'utilisateur avant exécution :

**1. Opérations destructives** (perte de données potentiellement irrécupérable)
- `git reset --hard` — supprime les modifications locales non commitées
- `git branch -D` — suppression sans vérification de merge
- `git clean -f` / `git clean -fd` — supprime fichiers/dossiers non suivis
- `git checkout -- .` / `git restore .` — écrase les modifs locales
- `rm -rf` sur fichiers versionnés non commités

**2. Opérations hard-to-reverse** (réécriture d'historique, signature défaillante)
- `git push --force` / `--force-with-lease` — réécrit l'historique distant
- `git rebase` sur branche partagée — réécrit l'historique
- `git commit --amend` sur commit déjà poussé — divergence d'historique
- `git filter-branch` / `git filter-repo` — réécriture massive
- `--no-verify` (skip hooks) / `--no-gpg-sign` — bypass de garde-fous

**3. Opérations visibles aux autres** (effet de bord sur systèmes partagés)
- `git push` vers main/master — visible publiquement
- `gh pr create` / `gh pr merge` — déclenche CI, notifications
- `gh issue close` / commentaires — visible par les autres contributeurs
- Modifications de tags ou releases (`git tag -d`, `git push --delete`)

**Quand on rencontre un obstacle, ne JAMAIS utiliser une action destructive comme raccourci.** Exemple : ne pas bypasser un hook qui échoue avec `--no-verify` — investiguer pourquoi le hook échoue et corriger la cause.

### En cas de conflit

- **Investiguer** avant de résoudre — comprendre les deux côtés du conflit
- Écraser silencieusement les changements d'un côté risque de casser des fonctionnalités
- En doute → demander à l'utilisateur quel côté préserver

## 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