À propos des branches protégées

À 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. Les acteurs peuvent être ajoutés uniquement pour contourner les listes quand le référentiel appartient à une organisation.

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 référentiel 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.

• Exiger des révisions de demande de tirage avant de fusionner
• Exiger des vérifications d’état avant la fusion
• Exiger la résolution de la conversation avant de fusionner
• Exiger des validations signées
• Exiger un historique linéaire
• Exiger que les déploiements réussissent avant de fusionner
• Verrouiller la branche
• Ne pas autoriser le contournement des paramètres ci-dessus
• Restreindre les personnes pouvant effectuer un envoi (push) à des branches correspondantes
• Autoriser les envois (push) forcés
• Autoriser les suppressions

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ôts ou les rôles personnalisés avec l’autorisation « modifier les règles de dépôt » peuvent exiger que toutes les demandes de tirage reçoivent un nombre spécifique de révisions d’approbation avant qu’une personne ne fusionne 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 les approbations de demande de tirage obsolètes lorsque des commits sont poussés et affectent le diff dans la demande de tirage. GitHub enregistre l’état du diff au moment où une demande de tirage est approuvée. Cet état représente l’ensemble des modifications approuvées par le réviseur. Si le diff sort de cet état (par exemple, parce qu’un contributeur pousse de nouvelles modifications vers la branche de demande de tirage ou clique sur Mettre à jour la branche, ou parce qu’une demande de tirage associée est fusionnée dans la branche cible), la révision d’approbation est ignorée car considérée comme obsolète et la demande de tirage ne peut pas être fusionnée tant qu’une personne n’approuve pas une nouvelle fois le travail. Pour plus d’informations sur la branche de base, consultez À propos des demandes de tirage (pull requests).

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 « Ignorer la révision d’une 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 que la poussée révisable la plus récente soit approuvée par une personne autre que la personne qui l’a faite. Cela signifie qu’au moins un autre réviseur autorisé approuve les modifications. Par exemple, le « dernier réviseur » peut vérifier que le dernier ensemble de modifications incorpore les commentaires d’autres révisions et n’ajoute pas de nouveau contenu non révisé.

Pour les demandes de tirage complexes qui nécessitent de nombreuses révisions, exiger l’approbation d’une personne autre que la dernière personne qui réalise la poussée peut être un compromis qui évite d’avoir à ignorer toutes les révisions obsolètes : avec cette option, les révisions « obsolètes » ne sont pas ignorées et la demande de tirage reste approuvée tant que quelqu’un d’autre que la personne qui a apporté les modifications les plus récentes l’approuve. 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. Si vous craignez que les demandes de tirage soient « détournées » (où que du contenu non approuvé soit ajouté aux demandes de tirage approuvées), il est plus sûr d’ignorer les révisions obsolètes.

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

Les vérifications d’état requises garantissent que tous les tests CI requis sont réussis ou ignorés 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 ».

Vous pouvez utiliser l’API d’état de commit pour autoriser les services externes à marquer les commits avec un état approprié. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les états de commit ».

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. Toutefois, dans certains cas, vous voudrez peut-être accepter uniquement la vérification d’état 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 prévue 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 requise	Paramètre	Exigences pour la fusion	Considérations
Strictes	La 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 une fois que les autres collaborateurs ont mis à jour la branche cible.
Lâches	La 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 obtenir des informations de 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 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 ».

Vous pouvez toujours envoyer (push) des validations locales à la branche si elles sont signées et vérifiées. Toutefois, vous ne pouvez pas fusionner des demandes de tirage dans la branche sur GitHub Enterprise Server. Vous pouvez les fusionner localement. Pour plus d’informations, consultez « Extraction de demandes de tirage localement ».

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 demande 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 demande de tirage ».

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 rend la branche accessible en lecture seule et garantit qu’aucune validation ne peut être effectuée sur la branche. Les branches verrouillées ne peuvent pas non plus être supprimées.

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 référentiel personnalisés pour une organisation ».

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

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 Enterprise Server bloque les poussées 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 une poussée forcée vers une branche, la poussée forcée peut signifier que les commits sur lesquels les autres collaborateurs ont basé leur travail sont supprimés de l’historique de la branche. Des personnes peuvent avoir des conflits de fusion ou des demandes de tirage endommagées. Une poussée forcée peut également être utilisée pour supprimer des branches ou pointer une branche vers des commits qui n’ont pas été approuvés dans une demande de tirage.

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.

Vous ne pouvez pas activer les envois (push) forcés pour une branche protégée si un administrateur de site a bloqué les envois (push) forcés à toutes les branches de votre dépôt. Pour plus d’informations, consultez « Application de stratégies de gestion des dépôts dans votre entreprise ».

Si un administrateur de site a bloqué les envois (push) forcés à la branche par défaut uniquement, vous pouvez toujours activer les envois (push) forcés pour toute autre branche protégée.

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.