Workflow de PR

Workflow complet pour passer des modifications de code locales par la création d'une branche, PR, vérification CI, correction d'erreurs, et merge.

Prérequis

Les modifications de code sont déjà effectuées et testées localement
Remote origin est configuré
gh CLI est authentifié

Étapes

1. Vérification préalable

git status
git diff --stat
git log --oneline -5

Vérifier avant de continuer :

Seuls les fichiers prévus sont modifiés
Aucun fichier sensible (.env, credentials) dans la staging area
Aucun artefact temporaire (screenshots, logs) laissé

2. Créer une branche

Brancher à partir du HEAD actuel. Convention de nommage :

Type	Préfixe	Exemple
Correction bug	`fix/`	`fix/remove-legacy-textarea`
Fonctionnalité	`feat/`	`feat/structured-ac-editor`
Refactor	`refactor/`	`refactor/service-layer`
Test	`test/`	`test/e2e-proposal-flow`
Docs	`docs/`	`docs/api-reference`
Chore	`chore/`	`chore/bump-deps`

git checkout -b {prefix}{short-description}

3. Stage et Commit

Stage uniquement les fichiers spécifiques — ne jamais utiliser git add . ou git add -A :

git add path/to/file1 path/to/file2

Note : Les chemins Next.js nécessitent un échappement shell :

git add src/app/\(dashboard\)/projects/\[uuid\]/file.tsx

Commit avec HEREDOC pour les messages multi-lignes propres :

git commit -m "$(cat <<'EOF'
{type}: {description concise du pourquoi, pas du quoi}

{Corps optionnel expliquant le contexte ou les compromis}

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
EOF
)"

4. Push et Ouvrir PR

git push -u origin {branch-name}

gh pr create --title "{type}: {titre sous 70 caractères}" --body "$(cat <<'EOF'
## Résumé
- Changement 1
- Changement 2

## Fichiers modifiés
| Fichier | Changement |
|---------|------------|
| `path/file.ts` | Quoi a changé |

## Plan de test
- [x] Test automatisé réussi
- [ ] Vérification manuelle nécessaire

Généré avec [Claude Code](https://claude.com/claude-code)
EOF
)"

5. Vérifier CI

gh pr checks {pr-number}

Tout passe — rapporter à l'utilisateur, prêt pour le merge
Une erreur — procéder à l'Étape 6

6. Corriger les échecs CI

Obtenir les logs échoués :

gh pr checks {pr-number}                          # trouver l'ID de la run échouée
gh run view {run-id} --log-failed 2>&1 | tail -80  # lire les détails d'erreur

Types d'erreurs courants et corrections :

Erreur	Reproduction locale	Correction
Assertion de test	`npx vitest run path/to/test.ts`	Mettre à jour les attentes de test pour correspondre au nouveau comportement
Erreur de type	`npx tsc --noEmit`	Corriger les types ; vérifier uniquement vos erreurs avec `\\| grep {keyword}`
Erreur lint	`pnpm lint`	Auto-fix ou correction manuelle
Test non mis à jour	`grep -r "changedField" src/**/__tests__/`	Mettre à jour les fixtures/helpers de test utilisant l'ancien champ

Après correction :

git add {fixed-files}
git commit -m "$(cat <<'EOF'
fix: {ce qui a été corrigé dans les tests/types}

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
EOF
)"
git push

Revérifier CI — répéter jusqu'au vert :

gh pr checks {pr-number}

7. Merge

Uniquement quand l'utilisateur le demande explicitement. Par défaut : squash merge :

gh pr merge {pr-number} --squash --delete-branch
git checkout main && git pull

Checklist

Avant d'ouvrir la PR :

[ ] npx tsc --noEmit passe (ou aucune nouvelle erreur)
[ ] Les tests associés passent localement
[ ] Aucun screenshot, fichier temporaire ou log de debug dans l'arborescence
[ ] Grep sur les fichiers de test pour tout changement de nom de champ/fonction

Avant de merger :

[ ] CI est vert
[ ] L'utilisateur a approuvé le merge

pr-workflow