Comment protéger la branche main sur GitHub avec les pull requests ?

Les règles de branche et les rulesets peuvent se combiner ; une protection supplémentaire peut bloquer un processus de livraison existant.

1. Ouvrir le dépôt puis Settings > Rules > Rulesets. Examiner les règles existantes et les protections de branches déjà configurées.
2. Relever la branche par défaut, les administrateurs, les équipes autorisées et les robots de publication éventuels.
3. Lister les workflows Actions déjà exécutés et le nom exact de leurs jobs, futurs contrôles obligatoires.

git remote -v
git branch --show-current
git fetch origin
git status --short

Une portée précise évite d’imposer par erreur les règles de production aux branches de développement.

1. Dans Settings > Rules > Rulesets, créer un nouveau branch ruleset et lui donner un nom explicite.
2. Choisir la branche main comme cible exacte ; examiner les règles héritées avant de régler le mode Enforcement sur Active.
3. Activer le blocage des suppressions et des force pushes, puis enregistrer les paramètres.

# Paramètres à vérifier dans l'interface GitHub :
# Cible : branche main
# Enforcement : Active
# Block force pushes : activé
# Restrict deletions : activé

La revue croisée réduit le risque d’intégrer un changement non examiné ou non documenté.

1. Activer Require a pull request before merging, puis définir au moins une approbation si l’organisation autorise cette option.
2. Activer la résolution obligatoire des conversations de revue si ce contrôle correspond au processus d’équipe.
3. Évaluer l’usage de CODEOWNERS pour les répertoires sensibles et éviter les dérogations individuelles permanentes.

# Exemple facultatif : fichier .github/CODEOWNERS
# Remplacer l'équipe par une équipe réellement existante.
# /infra/ @ORGANISATION/equipe-plateforme
# /.github/workflows/ @ORGANISATION/equipe-plateforme

Les validations automatiques permettent de bloquer une fusion en présence d’une erreur de compilation ou de tests.

1. Faire exécuter le workflow CI au moins une fois sur une pull request de recette.
2. Dans le ruleset, activer Require status checks to pass et sélectionner le nom exact du job constaté dans Checks.
3. Choisir l’option qui impose une branche à jour si le dépôt exige de revalider les changements intégrés entre-temps.

# Exemple de noms de contrôles :
# CI Node.js / checks
# Sélectionner uniquement un contrôle réellement publié
# par une exécution récente du dépôt.

Une règle enregistrée n’est pas suffisante : il faut vérifier son comportement réel avec les droits de l’équipe.

1. Créer une branche de recette pour modifier uniquement une documentation sans risque.
2. Pousser la branche, ouvrir la pull request et relever les statuts de revue et de CI affichés par GitHub.
3. Confirmer que les contrôles requis bloquent la fusion tant qu’ils ne sont pas satisfaits, puis clôturer la PR de test.

git switch -c docs/test-protection-main
git push --set-upstream origin docs/test-protection-main
# Ouvrir ensuite une pull request vers main dans GitHub.
# Ne pas forcer un push direct sur main pour effectuer le test.

Une gouvernance durable suppose de savoir qui intervient lorsque la CI, GitHub ou la livraison rencontre un incident.

1. Consigner les règles, leurs propriétaires, le nom des contrôles et la procédure de changement.
2. Vérifier la liste des acteurs autorisés à contourner les règles, ainsi que la traçabilité de leurs actions.
3. Prévoir un retour arrière contrôlé pour les évolutions de règles ; traiter l’urgence par une procédure documentée.

# Contrôles de gouvernance
# 1. Ruleset : cible main uniquement
# 2. Revue requise : oui
# 3. Jobs CI requis : noms exacts
# 4. Bypass : propriétaires identifiés
# 5. Procédure d'urgence : documentée