Comment configurer et maintenir les règles de protection des branches GitHub
La protection des branches est un élément important pour garantir qu'aucun accident ni erreur ne se produise dans votre référentiel GitHub.
La protection des branches est un élément important pour garantir qu'aucun accident ni erreur ne se produise dans votre référentiel GitHub. Ils appliquent des règles que toute personne souhaitant envoyer des commits ou fusionner des demandes d'extraction dans votre référentiel doit suivre.
Pourquoi la protection des succursales est-elle nécessaire ?
La protection des branches consiste à empêcher les actions indésirables. Vous pouvez définir des règles pour exiger des examens des demandes d'extraction, exiger que des tests soient effectués avant la fusion ou exiger des validations signées pour vérifier l'authenticité.
Par défaut, la protection des branches désactivera les poussées forcées et empêchera la suppression des branches. Ce sont deux choses que vous ne voulez jamais que cela se produise régulièrement, et jamais sans le consentement exprès de quelqu'un qui peut faire une exception et désactiver la protection de la branche.
C'est bon pour la sécurité, en particulier dans les projets plus importants ou les référentiels open source où les responsables souhaitent imposer un processus particulier de soumission et d'approbation pour les nouvelles modifications. Les branches peuvent également être entièrement verrouillées pour les non-administrateurs, ce qui peut être utilisé pour appliquer une autorisation supplémentaire aux branches de version/production.
La protection des branches, par défaut, ne s'appliquera pas aux administrateurs. Vous pouvez également donner aux personnes une autorisation spécifique leur permettant de le contourner. Si vous ne souhaitez pas que les administrateurs ou quiconque puisse contourner certaines règles, vous pouvez désactiver cette option pour chaque règle.
La protection des branches est disponible gratuitement pour les référentiels publics, mais n'est pas disponible pour les référentiels privés sans GitHub Team ou Enterprise.
À quoi servent les règles de protection des branches de GitHub ?
Il existe de nombreux paramètres que vous pouvez activer pour la protection des branches, et ils font tous des choses différentes. Voici quelques-uns des plus utiles :
- « Exiger des examens des demandes d'extraction avant la fusion » ne permettra pas aux PR d'être fusionnés dans des branches protégées jusqu'à ce qu'une ou plusieurs personnes autorisées aient approuvé la demande. Ceci est particulièrement utile pour empêcher une seule personne de fusionner elle-même un PR.
- « Exiger une résolution de conversation » garantira que seuls les PR fermés et finalisés pourront être fusionnés.
- « Exiger des vérifications de statut avant la fusion » s'intégrera à votre pipeline CI pour exécuter des tests sur les nouveaux commits afin de vérifier qu'ils ne cassent rien. GitHub dispose même d'une API de statut de validation que vous pouvez utiliser pour l'intégration externe.
- « Exiger que les déploiements réussissent » est généralement utilisé pour garantir que les builds sont correctement déployées dans les environnements de test avant d'être fusionnées.
- "Exiger un historique linéaire" empêche les validations de fusion d'être poussées vers la branche, ce qui nécessite que les fusions soient des fusions d'écrasement ou de rebase. L’historique de validation linéaire est préférable par de nombreuses équipes car il facilite grandement le suivi et la restauration des versions.
- « Exiger des validations signées » imposera que les validations soient signées GPG, vérifiant qu'elles ont été créées avec la clé privée de l'utilisateur et qu'elles n'ont pas été créées par un attaquant ayant un accès GitHub.
En plus de tout cela, vous pouvez également gérer directement les autorisations pour décider qui peut pousser vers la branche. Par exemple, il est courant que les branches de publication aient des restrictions supplémentaires afin qu'un stagiaire aléatoire ne puisse pas accidentellement passer en production.
Vous pouvez également verrouiller entièrement les branches, comme dans le cas des branches en amont qui ne devraient pas changer.
De plus, même si les administrateurs ont la possibilité de contourner ces règles par défaut, vous pouvez également désactiver cette fonctionnalité pour vous assurer que personne dans votre référentiel ne peut enfreindre les règles sans que celles-ci soient désactivées.
Comment configurer les règles de protection des branches GitHub
Les règles de protection des branches sont définies dans les paramètres du référentiel. Cliquez sur le bouton Paramètres de votre référentiel, puis cliquez sur « Protection des branches ».
Vous devez définir un filtre pour la règle de protection des branches. Vous pouvez simplement le définir sur le nom d'une branche spécifique, telle que « principale », ou vous pouvez utiliser des caractères génériques pour cibler plusieurs branches à la fois.
Un caractère générique illimité « * » s'appliquera à toutes les branches, et plusieurs règles de protection de branche peuvent s'empiler les unes sur les autres. Toutefois, vous ne pouvez pas avoir deux règles avec le même filtre.
Ensuite, vous aurez la possibilité de configurer chaque paramètre de protection de branche. Par défaut, seules les poussées et suppressions forcées sont désactivées, mais vous pouvez cocher n'importe laquelle des cases ici pour activer d'autres éléments de votre choix.
Une chose que vous souhaiterez activer la plupart du temps est la règle empêchant les administrateurs de contourner les règles.
Ensuite, vous pouvez activer la règle, mais vous devrez vous réauthentifier auprès de l'application mobile GitHub, car la modification des règles de protection des branches est une action restreinte. Vous pouvez tester s'il est activé en essayant de forcer le push --- votre client Git devrait afficher une erreur.