Github - Comment protéger sa branche (les Branch Protection Rules)

Après avoir ouvert récemment l'un de mes projets open source à être collaboratif j'ai reçu une demande de push sur mon repo. Et là j'ai un peu paniqué parce que je ne m'étais pas penché sur la question de protection autour de mes projets persos.

Documentation Github sous les yeux et ChatGPT à côté pour m'épauler je me suis empressée de mettre en place ma première Branch Protection Rules (BPR).

À quoi sert une BPR ?

Sur vos branches critiques (en général la principale - main) il est important de cadrer les interactions qu'ont les collaborateurs sur celles-ci. Que ce soit pour supprimer, forcer les envois ou encore contrôler l'historique il est recommandé de définir des exigences (ou un workflow personnalisé) pour gérer au mieux votre projet.

---

Les options possibles

📝 Contrôler les contributions

• Exiger une pull request avant de fusionner.
• Exiger un nombre minimal d'approbations (utile pour les grosses équipes).
• Supprimer les approbations lorsqu'un nouveau commit est poussé.
• Exiger une revue d'un mainteneur ou administrateur du projet.
• Exiger que les approbations viennent d'une personne différente que celle qui l'a poussé.
• Empêcher la fusion lorsque les discussions sont encore ouvertes.

🔒 Sécuriser les commits

• Exiger des commits signés (ou vérifiés avec une clé SSH, très utilisé en entreprise).
• Interdire les pushs forcés (git push -f).
• Empêcher la suppression de la branche.

✅ La validation automatique

• Exiger des tests réussis avant une fusion (c'est toute la partie CI/CD -que je n'ai encore jamais exploré-).
• Exiger un historique de commits linéaire pour un historique clair avec des commits isolés et sans merges inutiles.

🚫 Restrictions avancées

• Limiter les pushs à certaines personnes/équipes.
• Restreindre les modifications sur des fichiers spécifiques (comme le package.json par exemple).

---

Quand et comment configurer une BPR ?

Activer la protection des branches n'est pas toujours nécessaire. Si votre projet est personnel et ne vise ni l'open source ni la collaboration, ces règles sont optionnelles.

👩‍💻 Projet perso

Comme indiqué plus haut mettre en place des restrictions strictes est optionnel. Il peut être par contre utile pour éviter les erreurs (comme un push forcé sur la branche principale).

🤝 Projet open source (avec une petite communauté)

• Exiger des pull requests avant de fusionner.
• Activer les revues de code (au moins 1 approbation avant merge).
• Empêcher les pushs forcés.
• Laisser la possibilité à l'admin de contourner les règles si nécessaire (optionnel). C'est ce que j'ai choisi sur mon projet en plus d'activer l'historique linéaire (optionnel).

🏢 Projet en équipe (pour des projets d'entreprise ou plus structurés)

En plus des exigences classiques pour les projets open source on ajoute une surcouche de protection:

• Exiger des commits signés.
• Exiger une validation CI/CD avant merge (souvent géré par des DevOps).
• Limiter les pushs aux personnes autorisées sur main.
• Augmenter le nombre de revues de code.
• Exiger la résolution des discussions avant de fusionner.
• Restreindre la modification de fichiers sensibles comme .github/workflows/ ou autres.

👀 Où configurer ça sur GitHub ?

📌 Repo > Settings > Branches > Add branch protection rule
👉 Documentation Github sur le sujet

Et Voilà, vous savez maintenant comment protéger vos branches si besoin. C'est une bonne pratique qui s'adapte au projet et qui rendent les workflows plus fluides et plus sûrs.

Et vous, comment protégez-vous vos branches sur vos projets persos ?