Comment configurer et gérer les règles de protection des branches GitHub

La protection des branches est un élément important pour s’assurer que les accidents et les erreurs ne se produisent pas dans votre référentiel GitHub. Ils appliquent des règles que toute personne souhaitant pousser 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 révisions de demande 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 fondamentalement jamais voir se produire 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 grands projets ou les référentiels open source où les responsables souhaitent appliquer un processus de soumission et d’approbation particulier 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 publication/production.

La protection des branches, par défaut, ne s’appliquera pas aux administrateurs. Vous pouvez également donner aux utilisateurs une autorisation spécifique leur permettant de le contourner. Si vous ne voulez pas que les administrateurs ou toute autre personne puissent 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.

Que font 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 de demande d’extraction avant de fusionner » n’autorisera pas la fusion de PR dans des branches protégées tant qu’une ou plusieurs personnes autorisées n’auront pas 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 sont autorisés à ê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 a même une API de statut de validation que vous pouvez utiliser pour une intégration externe.
• « Exiger que les déploiements réussissent » est généralement utilisé pour s’assurer que les builds sont correctement déployés dans les environnements intermédiaires avant d’être fusionnés.
• « 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 de squash ou de rebase. L’historique de validation linéaire est préférable pour de nombreuses équipes, car il facilite grandement le suivi et la restauration des versions.
• « Exiger des commits signés » obligera les commits à être signés GPG, en vérifiant qu’ils ont été créés avec la clé privée de l’utilisateur et non créés par un attaquant avec 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’aucun stagiaire aléatoire ne puisse 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, bien que les administrateurs aient la possibilité de contourner ces règles par défaut, vous pouvez également les désactiver, en vous assurant que personne dans votre référentiel ne peut enfreindre les règles sans que les règles ne 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 des 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 de branche. 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. Cependant, 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 forcées et les suppressions sont désactivées, mais vous pouvez activer l’une des cases à cocher ici pour activer d’autres choses que vous voulez.

Une chose que vous voudrez 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, bien que vous deviez vous authentifier à nouveau avec 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.