Utilise issues, protections de branche et règles de fusion

01Transforme le besoin en issue

# Activer le contrôle de sauvegarde

## Problème
Le staging ne rend pas visible l’état de la dernière sauvegarde.

## Critères d’acceptation
- le check est activé ;
- le résultat attendu est documenté ;
- le rollback est testé ;
- la modification passe par une PR et la CI.

Une issue décrit le problème et le résultat attendu. Elle ne doit pas imposer prématurément une implémentation si plusieurs solutions sont possibles.

02Relie issue, branche, commits et PR

Issue #42
└── feature/backup-healthcheck
    ├── feat: enable backup health check
    ├── docs: add validation runbook
    └── Pull request: Closes #42

La référence crée une chaîne de traçabilité entre demande, exécution, revue et intégration.

03Protège les branches qui livrent

main
- pull request obligatoire
- au moins une approbation
- checks requis
- force push interdit
- suppression interdite

dev
- pull request et checks requis
- déploiement automatique vers staging

Les règles de main peuvent être plus strictes que celles d’une branche d’intégration, mais les deux doivent empêcher un contournement accidentel du pipeline.

04Choisis protection classique ou ruleset

Évite les règles qui se chevauchent sans documentation. L’équipe doit savoir quelle politique s’applique réellement à chaque branche.

05Exige les bons checks

Checks minimaux d’un site content-as-code
- validation du repository ;
- syntaxe des scripts téléchargeables ;
- exécution des labs compatibles avec l’agent ;
- validation du schema et build MDX ;
- contrôle des artefacts ;
- smoke test du contenu déployé.

Les noms de checks requis doivent être stables et non ambigus. Un check requis ne prouve que le périmètre réellement exécuté.

06Définis la politique de revue

[ ] une approbation indépendante
[ ] nouvelles modifications ⇒ nouvelle validation
[ ] conversation bloquante résolue
[ ] auteur différent du reviewer si possible
[ ] exception documentée pour urgence
[ ] restauration ou revert prévu

07Choisis une méthode de fusion

La méthode doit correspondre à la politique d’historique. Elle ne compense pas une PR trop grande ou non testée.

08Diagnostique une fusion bloquée

gh pr view
gh pr checks
gh pr diff
git fetch origin
git log --left-right --oneline origin/dev...HEAD

Causes fréquentes
- check requis absent ou en échec ;
- branche non à jour selon la règle ;
- approbation devenue obsolète ;
- conversation non résolue ;
- règle de signature ou d’historique non satisfaite ;
- acteur sans droit de bypass.

09Valide la politique hors ligne

cat /tmp/soria-git-github-$USER/evidence/issue.md
cat /tmp/soria-git-github-$USER/evidence/branch-rules.json
bash module4-github-collaboration.sh validate \
  /tmp/soria-git-github-$USER

Le JSON est une spécification pédagogique. Il ne configure pas GitHub automatiquement et ne remplace pas la vérification des paramètres réels du repository.