Skip to main content

À propos des branches protégées

Vous pouvez protéger les branches importantes en définissant des règles de protection des branches, qui déterminent si les collaborateurs peuvent supprimer ou forcer les envois vers la branche, et qui définissent les exigences pour tous les envois vers la branche, comme la réussite des contrôles d’état ou un historique linéaire des validations.

Les branches protégées sont disponibles dans les dépôts publics avec GitHub Free et GitHub Free pour les organisations, et dans les dépôts publics et privés avec GitHub Pro, GitHub Team, GitHub Enterprise Cloud et GitHub Enterprise Server. Pour plus d’informations, consultez « Produits de GitHub ».

À propos des règles de protection de branche

Vous pouvez appliquer certains workflows ou exigences avant qu’un collaborateur puisse envoyer (push) des modifications à une branche dans votre dépôt, dont la fusion d’une demande de tirage dans la branche, en créant une règle de protection de branche.

Par défaut, chaque règle de protection de branche désactive les envois (push) forcés aux branches correspondantes, et empêche la suppression de celles-ci. Vous pouvez éventuellement désactiver ces restrictions et activer des paramètres de protection de branche supplémentaires.

Par défaut, les restrictions d’une règle de protection des branches ne s’appliquent pas aux personnes qui ont des autorisations d’administrateur sur le dépôt ni aux rôles personnalisés avec l’autorisation « Contourner les protections de branche ». Vous pouvez éventuellement appliquer les restrictions aux administrateurs et aux rôles avec l’autorisation « Contourner les protections de branche », également. Pour plus d’informations, consultez « Gestion des rôles de dépôt personnalisés pour une organisation ».

Vous pouvez créer une règle de protection de branche dans un référentiel pour une branche spécifique, pour toutes les branches ou pour toute branche qui correspond à un modèle de nom que vous spécifiez avec la syntaxe fnmatch. Par exemple, pour protéger toutes les branches contenant le mot release, vous pouvez créer une règle de branche pour *release*. Pour plus d’informations sur les modèles de nom de branche, consultez « Gestion d’une règle de protection de branche ».

Vous pouvez configurer une demande de tirage pour fusionner automatiquement lorsque toutes les conditions de fusion sont remplies. Pour plus d’informations, consultez « Fusion automatique d’une demande de tirage ».

À propos des paramètres de protection de branche

Pour chaque règle de protection de branche, vous pouvez choisir d’activer ou de désactiver les paramètres suivants.

Pour plus d’informations sur la configuration de la protection de branche, consultez « Gestion d’une règle de protection de branche ».

Exiger des révisions de demande de tirage avant de fusionner

Les administrateurs de dépôt peuvent exiger que toutes les demandes de tirage reçoivent un nombre spécifique de révisions d’approbation avant que quelqu’un puisse fusionner la demande de tirage dans une branche protégée. Vous pouvez demander des révisions d’approbation à des personnes qui ont des autorisations d’écriture sur le dépôt ou à un propriétaire de code désigné.

Si vous activez les révisions requises, des collaborateurs ne peuvent envoyer (push) des modifications à une branche protégée que via une demande de tirage approuvée par le nombre requis de réviseurs disposant d’autorisations d’écriture.

Si une personne disposant d’autorisations d’administration choisit l’option Demander des modifications dans une révision, elle doit approuver la demande de tirage avant que celle-ci puisse être fusionnée. Si un réviseur qui demande des modifications sur une demande de tirage n’est pas disponible, toute personne disposant d’autorisations d’écriture sur le dépôt peut ignorer la révision bloquante.

Même si tous les réviseurs obligatoires ont approuvé une demande de tirage, les collaborateurs ne peuvent pas fusionner la demande de tirage si d’autres demandes de tirage ouvertes ont une branche principale qui pointe vers le même commit avec des révisions en attente ou rejetées. Une personne avec des autorisations d’écriture doit d’abord approuver ou ignorer la révision bloquante sur les autres demandes de tirage.

Si un collaborateur tente de fusionner une demande de tirage avec des révisions en attente ou rejetées dans la branche protégée, il reçoit un message d’erreur.

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.

Si vous le souhaitez, vous pouvez choisir d’ignorer des approbations de demandes de tirage obsolètes lors de l’envoi (push) de validations. Si quelqu’un envoie (push) une validation qui modifie le code d’une demande de tirage approuvée, l’approbation est ignorée et la demande de tirage ne peut pas être fusionnée. Cela ne s’applique pas si le collaborateur envoie des validations qui ne modifient pas de code, comme la fusion de la branche de base dans la branche de la demande de tirage. Pour plus d’informations sur la branche de base, consultez « À propos des demandes de tirage ».

Si vous le souhaitez, vous pouvez restreindre la possibilité d’ignorer des révisions des demandes de tirage à des personnes ou équipes spécifiques. Pour plus d’informations, consultez « Abandonner une revue de demande de tirage ».

Si vous le souhaitez, vous pouvez choisir d’exiger des révisions des propriétaires de code. Dans ce cas, toute demande de tirage affectant un code ayant un propriétaire doit être approuvée par celui-ci avant qu’elle puisse être fusionnée dans la branche protégée.

Si vous le souhaitez, vous pouvez exiger des approbations d’une autre personne que la dernière personne qui effectue une poussée vers une branche avant qu’une demande de tirage puisse être fusionnée. Cela garantit que plusieurs personnes voient les demandes de tirage dans leur état final avant qu’elles ne soient fusionnées dans une branche protégée. Si vous activez cette fonctionnalité, le dernier utilisateur qui pousse ses modifications a besoin d’une approbation, quelle que soit la protection de branche d’approbation requise. Les utilisateurs qui ont déjà révisé une demande de tirage peuvent effectuer une nouvelle approbation après la poussée la plus récente pour répondre à cette exigence.

Exiger des vérifications d’état avant la fusion

Les vérifications d’état requises garantissent que tous les tests CI requis ont réussi avant que des collaborateurs puissent apporter des modifications à une branche protégée. Les vérifications d’état requises peuvent être des vérifications ou des états. Pour plus d’informations, consultez « À propos des vérifications d’état ».

Avant de pouvoir activer des vérifications d’état requises, vous devez configurer le dépôt pour utiliser l’API d’état de commit. Pour plus d’informations, consultez « États de commit » dans la documentation de l’API REST.

Une fois que des vérifications d’état requises sont activées, elles doivent toutes réussir avant que des collaborateurs puissent fusionner des modifications dans la branche protégée. Une fois que toutes les vérifications d’état requises ont réussi, toutes les validations doivent être soit envoyées (push) à une autre branche, puis fusionnées, soit envoyées directement à la branche protégée.

Toute personne ou intégration disposant d’autorisations d’écriture sur un dépôt peut définir l’état de toute vérification d’état dans le dépôt mais, dans certains cas, il se peut que vous ne vouliez accepter de vérification d’état que d’une GitHub App spécifique. Lorsque vous ajoutez une vérification d’état requise, vous pouvez sélectionner une application qui a récemment défini cette vérification comme source attendue des mises à jour d’état. Si l’état est défini par une autre personne ou intégration, la fusion n’est pas autorisée. Si vous sélectionnez « toute source », vous pouvez toujours vérifier manuellement l’auteur de chaque état, répertorié dans la zone de fusion.

Vous pouvez configurer des vérifications d’état requises « lâches » ou « strictes ». Le type de vérification d’état requise que vous choisissez détermine si votre branche doit être à jour avec la branche de base avant de la fusion.

Type de vérification d’état requiseParamètreExigences pour la fusionConsidérations
StrictesLa case à cocher Exiger que les branches soient à jour avant la fusion est activée.La branche doit être à jour avec la branche de base avant la fusion.Il s’agit du comportement par défaut pour les vérifications d’état requises. D’autres builds peuvent être requises, car vous devez mettre à jour la branche principale après que d’autres collaborateurs ont fusionné des demandes de tirage dans la branche de base protégée.
LâchesLa case à cocher Exiger que les branches soient à jour avant la fusion n’est pas activée.La branche ne doit pas être à jour avec la branche de base avant la fusion.Vous aurez moins de builds requises, car vous n’aurez pas besoin de mettre à jour la branche principale après que d’autres collaborateurs auront fusionné des demandes de tirage. Des vérifications d’état peuvent échouer après que vous avez fusionné votre branche s’il existe des modifications incompatibles avec la branche de base.
DésactivéLa case à cocher Exiger la réussite des vérifications d’état avant de fusionner n’est pas activée.La branche n’a aucune restriction de fusion.Si les vérifications d’état requises ne sont pas activées, des collaborateurs peuvent fusionner la branche à tout moment, qu’elle soit ou non à jour avec la branche de base. Cela augmente la possibilité de modifications incompatibles.

Pour des informations sur la résolution des problèmes, consultez « Résolution des problèmes liés aux vérifications de statut requises ».

Exiger la résolution de la conversation avant de fusionner

Exige que tous les commentaires sur la demande de tirage soient résolus avant que celle-ci puisse être fusionnée dans une branche protégée. Cela garantit que tous les commentaires ont été traités ou ont fait l’objet d’un accusé de réception avant la fusion.

Exiger des validations signées

Lorsque vous activez la signature de validation requise sur une branche, des contributeurs et des bots ne peuvent envoyer (push) à la branche que des validations signées et vérifiées. Pour plus d’informations, consultez « À propos de la vérification des signatures de commit ».

Remarques :

  • Si vous avez activé le mode vigilant, ce qui indique que vos validations seront toujours signées, toutes les validations que GitHub identifie comme « Partiellement vérifiés » sont autorisées sur des branches exigeant des validations signées. Pour plus d’informations sur le mode vigilant, consultez « Affichage des états de vérification pour toutes vos validations ».
  • Si un collaborateur envoie (push) une validation non signée à une branche qui exige des signatures de validation, ce collaborateur devra rebaser la validation pour inclure une signature vérifiée, puis effectuer un envoi (push) forcé de la validation réécrite à la branche.

Vous pouvez toujours envoyer (push) des validations locales à la branche si elles sont signées et vérifiées. Vous pouvez également fusionner des validations signées et vérifiées dans la branche à l’aide d’une demande de tirage sur GitHub. En revanche, vous ne pouvez pas effectuer de « squash and merge » sur une demande de tirage dans la branche sur GitHub, sauf si vous en êtes l’auteur. Vous pouvez effectuer un « squash » sur des demandes de tirage et les fusionner localement. Pour plus d’informations, consultez « Extraction des demandes de tirage localement ».

Pour plus d’informations sur les méthodes de fusion, consultez « À propos des méthodes de fusion sur GitHub ».

Exiger un historique linéaire

L’application d’un historique de validation linéaire empêche des collaborateurs d’envoyer (push) des validations de fusion à la branche. Cela signifie que toutes les demandes de tirage fusionnées dans la branche protégée doivent utiliser une fusion « squash » ou « rebase ». Un historique de validation strictement linéaire peut aider les équipes à inverser des modifications plus facilement. Pour plus d’informations sur les méthodes de fusion, consultez « À propos des fusions de demandes de tirage ».

Avant de pouvoir exiger un historique de validation linéaire, votre dépôt doit autoriser une fusion « squash » ou « rebase ». Pour plus d’informations, consultez « Configuration des fusions de demandes de tirage ».

Exiger une file d’attente de fusion

Remarque : La fonctionnalité de file d’attente de fusion des demandes de tirage est actuellement en version bêta publique limitée et susceptible de changer.

Une file d’attente de fusion peut augmenter le débit de fusion des demandes de tirage dans une branche cible occupée tout en veillant à la réussite de toutes les vérifications de protection de branche nécessaires.

Dès qu’une demande de tirage a réussi toutes les vérifications de protection de branche nécessaires, un utilisateur avec un accès en écriture sur le dépôt peut ajouter cette demande de tirage à une file d’attente de fusion.

Une file d’attente de fusion peut utiliser GitHub Actions. Pour plus d’informations, consultez « GitHub Actions ».

GitHub fusionne la demande de tirage en fonction de la stratégie de fusion configurée dans la protection de branche une fois que toutes les vérifications CI nécessaires sont réussies.

Méthode de fusion de la file d’attente de fusion Pour plus d’informations sur la file d’attente de fusion, consultez « Gestion d’une file d’attente de fusion ».

Exiger que les déploiements réussissent avant de fusionner

Vous pouvez exiger que des modifications aient été déployées avec succès dans des environnements spécifiques avant qu’une branche puisse être fusionnée. Par exemple, vous pouvez utiliser cette règle pour vous assurer que les modifications ont été déployées avec succès dans un environnement intermédiaire avant la fusion des modifications dans votre branche par défaut.

Verrouiller une branche

Le verrouillage d’une branche garantit qu’aucun commit ne peut être effectué sur la branche. Par défaut, un dépôt dupliqué ne prend pas en charge la synchronisation à partir de son dépôt en amont. Vous pouvez activer Autoriser la synchronisation de la duplication pour tirer des modifications du dépôt en amont tout en empêchant d’autres contributions à la branche de la duplication.

Ne pas autoriser le contournement des paramètres ci-dessus

Par défaut, les restrictions d’une règle de protection des branches ne s’appliquent pas aux personnes qui ont des autorisations d’administrateur sur le dépôt ni aux rôles personnalisés avec l’autorisation « Contourner les protections de branche » sur un dépôt.

Vous pouvez activer ce paramètre pour appliquer les restrictions aux administrateurs et aux rôles avec l’autorisation « Contourner les protections de branche », également. Pour plus d’informations, consultez « Gestion des rôles de dépôt personnalisés pour une organisation ».

Restreindre les personnes pouvant effectuer un envoi (push) à des branches correspondantes

Vous pouvez activer des restrictions de branche dans les dépôts publics appartenant à une organisation GitHub Free et dans tous les dépôts appartenant à une organisation utilisant GitHub Team ou GitHub Enterprise Cloud.

Lorsque vous activez des restrictions de branche, seuls des utilisateurs, équipes ou applications autorisés peuvent effectuer un envoi (push) à la branche protégée. Vous pouvez afficher et modifier les utilisateurs, équipes ou applications disposant d’un accès en envoi (push) à une branche protégée dans les paramètres de la branche protégée. Lorsque des vérifications d’état sont requises, les personnes, équipes et applications disposant de l’autorisation d’effectuer un envoi (push) à une branche protégée sont toujours empêchées d’opérer une fusion dans la branche quand les vérifications requises échouent. Les personnes, équipes et applications disposant de l’autorisation d’effectuer un envoi (push) à une branche protégée doivent toujours créer une demande de tirage quand des demandes de tirage sont requises.

Si vous le souhaitez, vous pouvez appliquer les mêmes restrictions à la création de branches correspondant à la règle. Par exemple, si vous créez une règle qui n’autorise qu’une certaine équipe à effectuer un envoi (push) à toutes les branches contenant le mot release, seuls les membres de cette équipe pourront créer une branche contenant le mot release.

Vous ne pouvez donner l’accès en envoi (push) à une branche protégée, ou accorder l’autorisation de créer une branche correspondante, qu’à des utilisateurs, équipes ou GitHub Apps disposant d’un accès en écriture à un dépôt. Les personnes et applications disposant d’autorisations d’administration sur un dépôt sont toujours en mesure d’effectuer un envoi (push) à une branche protégée ou de créer une branche correspondante.

Autoriser les envois (push) forcés

Par défaut, GitHub bloque les poussées (push) forcées sur toutes les branches protégées. Lorsque vous activez les envois (push) forcés à une branche protégée, vous avez le choix entre deux groupes pouvant effectuer des envois (push) forcés :

  1. Autoriser toute personne disposant au moins d’autorisations d’écriture sur le dépôt à effectuer un envoi (push) forcé à la branche, y compris si cette personne dispose d’autorisations d’administration.
  2. Autorisez uniquement des personnes ou équipes spécifiques effectuer un envoi (push) forcé à la branche.

Si quelqu’un effectue un envoi (push) forcé à une branche, cet envoi peut remplacer des validations sur lesquelles d’autres collaborateurs ont basé leur travail. Des personnes peuvent avoir des conflits de fusion ou des demandes de tirage endommagées.

L’activation des envois (push) forcés ne remplace aucune autre règle de protection de branche. Par exemple, si une branche nécessite un historique de validation linéaire, vous ne pouvez envoyer (push) de force des validations de fusion à cette branche.

Autoriser les suppressions

Par défaut, vous ne pouvez pas supprimer une branche protégée. Lorsque vous activez la suppression d’une branche protégée, toute personne disposant d’autorisations d’écriture sur le dépôt peut supprimer la branche.