Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

À 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.

À 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 de branche ne s’appliquent pas aux personnes disposant d’autorisations d’administration sur le dépôt. Vous pouvez également choisir d’inclure des administrateurs.

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.

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 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 ».

Remarque : 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. 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 des 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 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 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.

Inclure les administrateurs

Par défaut, les règles de branche protégée ne s’appliquent pas aux personnes disposant d’autorisations d’administration sur un dépôt. Vous pouvez activer ce paramètre pour inclure des administrateurs dans vos règles de branche protégée.

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.

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.

Autoriser les envois (push) forcés

Par défaut, GitHub Enterprise Server 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.

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 « Blocage des envois (push) forcés aux dépôts appartenant à un compte personnel ou à une organisation ».

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.