Système de prompt expert en flux de travail Git

# Expert Git Workflow ## Contexte - **Structure du dépôt** : Monorepo avec des applications frontend et backend séparées, utilisant actuellement une stratégie de branchement simple avec une branche principale et des branches de fonctionnalités. - **Modèle de branchement actuel** : Branche principale unique avec des branches de fonctionnalités fusionnées directement dans la branche principale. - **Taille de l'équipe** : 8 développeurs travaillant sur plusieurs fonctionnalités simultanément. - **Modèles de collaboration** : Demandes de tirage avec revue par les pairs, revues obligatoires sur la branche principale. - **Pipeline CI/CD** : GitHub Actions pour les tests et le déploiement, avec des déploiements automatiques sur les environnements de préproduction et de production. ## Plan de flux de travail - [ ] **GIT-PLAN-1.1 [Stratégie de branchement]** : - **Modèle** : Adopter Git Flow pour une meilleure gestion des versions et des correctifs. - **Branches** : Branches à longue durée de vie : `main`, `develop` ; Branches éphémères : `feature/*`, `release/*`, `hotfix/*`. - **Protection** : `main` et `develop` nécessitent des revues obligatoires, des vérifications CI, et aucune poussée forcée. - **Nommage** : `feature/description-courte`, `release/version`, `hotfix/description-courte`. - [ ] **GIT-PLAN-1.2 [Règles de protection des branches]** : - **Branches protégées** : `main`, `develop`. - **Exigences** : Au moins 1 approbation, vérifications CI réussies, aucune poussée forcée. - **Fichiers CODEOWNERS** : Attribuer automatiquement les propriétaires pour les chemins critiques. - [ ] **GIT-PLAN-1.3 [Conventions de validation]** : - **Format** : Adopter les validations conventionnelles (`feat:`, `fix:`, `chore:`, `docs:`, `refactor:`). - **Portée** : Inclure la portée du changement (par exemple, `feat(api): ajouter un point de terminaison de connexion`). - **Application** : Utiliser commitlint pour valider le format des messages de validation. ## Éléments du flux de travail - [ ] **GIT-ITEM-1.1 [Configuration des hooks Git]** : - **Hook** : Hook pre-commit. - **Objectif** : Exécuter des linters et des vérifications de formatage sur les fichiers modifiés. - **Outil** : Husky avec lint-staged. - **Repli** : Si le hook échoue, le commit est bloqué et le développeur doit corriger les problèmes. - [ ] **GIT-ITEM-1.2 [Validation des messages de validation]** : - **Hook** : Hook commit-msg. - **Objectif** : Valider le format des messages de validation selon les conventions. - **Outil** : commitlint. - **Repli** : Si le message est invalide, le commit est bloqué et le développeur doit reformuler le message. - [ ] **GIT-ITEM-1.3 [Tests avant poussée]** : - **Hook** : Hook pre-push. - **Objectif** : Exécuter la suite de tests avant de pousser les branches. - **Outil** : Script personnalisé dans Husky. - **Repli** : Si les tests échouent, la poussée est bloquée et le développeur doit corriger les problèmes. - [ ] **GIT-ITEM-1.4 [Intégration CI/CD]** : - **Hook** : Workflow GitHub Actions. - **Objectif** : Exécuter les tests, le linting et le déploiement sur les événements de branche et de demande de tirage. - **Outil** : GitHub Actions. - **Repli** : Si les vérifications CI échouent, la fusion est bloquée. ## Modifications de code proposées ### Fichier : `.husky/pre-commit` ```bash #!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh" npx lint-staged ``` ### Fichier : `.husky/commit-msg` ```bash #!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh" npx --no -- commitlint --edit "$1" ``` ### Fichier : `.husky/pre-push` ```bash #!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh" npm test ``` ### Fichier : `.lintstagedrc.json` ```json { "*.{js,jsx,ts,tsx}": ["eslint --fix", "prettier --write"], "*.{json,md,yml,yaml}": ["prettier --write"] } ``` ### Fichier : `commitlint.config.js` ```javascript module.exports = { extends: ['@commitlint/config-conventional'], rules: { 'type-enum': [2, 'always', ['feat', 'fix', 'chore', 'docs', 'refactor', 'test']], 'subject-case': [2, 'never', ['sentence-case', 'start-case', 'pascal-case', 'upper-case']] } }; ``` ### Fichier : `.github/workflows/ci.yml` ```yaml name: CI on: push: branches: [main, develop] pull_request: branches: [main, develop] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: '18' - run: npm ci - run: npm run lint - run: npm test ``` ### Fichier : `.github/CODEOWNERS` ``` # Propriétaires par défaut pour tout le dépôt * @team-lead # Propriétaires pour le code backend /api/ @backend-team # Propriétaires pour le code frontend /frontend/ @frontend-team ``` ## Commandes ### Configuration locale ```bash # Installer Husky npm install --save-dev husky # Activer les hooks npx husky install # Ajouter les hooks npx husky add .husky/pre-commit "npx lint-staged" npx husky add .husky/commit-msg "npx --no -- commitlint --edit \"$1\"" npx husky add .husky/pre-push "npm test" # Installer lint-staged et commitlint npm install --save-dev lint-staged @commitlint/cli @commitlint/config-conventional # Créer les fichiers de configuration echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js echo '{ "*.{js,jsx,ts,tsx}": ["eslint --fix", "prettier --write"] }' > .lintstagedrc.json ``` ### Configuration CI ```bash # Ajouter le workflow CI mkdir -p .github/workflows # Créer .github/workflows/ci.yml avec le contenu ci-dessus # Ajouter le fichier CODEOWNERS mkdir -p .github # Créer .github/CODEOWNERS avec le contenu ci-dessus ``` ## Liste de contrôle de l'assurance qualité - [ ] Toutes les commandes proposées sont sûres et incluent des instructions de restauration. - [ ] Les règles de protection des branches couvrent toutes les branches critiques. - [ ] Les hooks Git sont compatibles multiplateformes (Windows, macOS, Linux). - [ ] Les conventions de messages de validation sont documentées et applicables. - [ ] Des procédures de récupération existent pour chaque opération destructive. - [ ] Le flux de travail s'intègre aux pipelines CI/CD existants. - [ ] Un plan de communication d'équipe existe pour les changements de flux de travail.