Skip to main content

Enterprise Server 3.15 est actuellement disponible en tant que version finale (RC).

Gestion d’une règle de protection de branche

Vous pouvez créer une règle de protection de branche pour appliquer certains workflows dans une ou plusieurs branches, par exemple exiger une révision d’approbation ou passer des vérifications d’état pour toutes les demandes de tirage (pull requests) fusionnées dans la branche protégée.

Qui peut utiliser cette fonctionnalité ?

People with admin permissions or a custom role with the "edit repository rules" permission to a repository can manage branch protection rules.

Les branches protégées sont disponibles dans les référentiels publics avec GitHub Free et GitHub Free pour les organisations. Les branches protégées sont également disponibles dans des référentiels 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 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*.

Vous pouvez créer une règle pour toutes les branches actuelles et futures dans votre dépôt avec la syntaxe générique *. Étant donné que GitHub utilise l’indicateur File::FNM_PATHNAME pour la syntaxe File.fnmatch, le caractère générique * ne correspond pas aux séparateurs de répertoires (/). Par exemple, qa/* correspond à toutes les branches commençant par qa/ et contenant une barre oblique unique, mais ne correspond pas à qa/foo/bar. Vous pouvez inclure n’importe quel nombre de barres obliques après qa avec qa/**/*, qui correspondrait, par exemple, à qa/foo/bar/foobar/hello-world. Vous pouvez également étendre la chaîne qa avec qa**/**/* pour rendre la règle plus inclusive.

Pour plus d’informations sur les options de syntaxe, consultez la documentation fnmatch.

Si un dépôt a plusieurs règles de branches protégées qui affectent les mêmes branches, les règles qui incluent un nom de branche spécifique ont la priorité la plus élevée. Si plusieurs règles de branche protégée référencent le même nom de branche spécifique, la règle de branche créée en premier aura une priorité plus élevée.

Les règles de branches protégées qui mentionnent un caractère spécial, tel que *, ? ou ], sont appliquées dans l’ordre dans lequel elles ont été créées ; les règles les plus anciennes avec ces caractères ont donc une priorité plus élevée.

Pour créer une exception à une règle de branche existante, vous pouvez créer une règle de protection de branche de priorité plus élevée, telle qu’une règle de branche pour un nom de branche spécifique.

Pour plus d’informations sur chacun des paramètres de protection de branche disponibles, consultez « À propos des branches protégées ».

Remarque : Une seule règle de protection de branche peut s’appliquer à la fois, ce qui signifie qu’il peut être difficile de savoir quelle règle s’applique quand plusieurs versions d’une règle ciblent la même branche. De plus, vous voudrez peut-être créer un seul ensemble de règles qui s’applique à plusieurs dépôts d’une organisation. Pour plus d’informations sur une alternative aux règles de protection de branche, consultez « À propos des ensembles de règles ».

Création d’une règle de protection de branche

Lorsque vous créez une règle de branche, la branche que vous spécifiez n’a pas encore besoin d’exister dans le dépôt.

Remarque : les acteurs peuvent être ajoutés uniquement pour contourner les listes quand le référentiel appartient à une organisation.

  1. Sur GitHub, accédez à la page principale du référentiel.

  2. Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.

    Capture d’écran d’un en-tête de dépôt montrant les onglets. L’onglet « Paramètres » est mis en évidence avec un encadré orange foncé.

  3. Dans la section « Code et automatisation » de la barre latérale, cliquez sur Branches.

  4. À côté de « Règles de protection de branche », cliquez sur Ajouter une règle.

  5. Sous « Modèle de nom de branche », tapez le nom ou le modèle de branche à protéger.

  6. Si vous le souhaitez, activez les demandes de tirage (pull requests) requises.

    Note

    Si vous sélectionnez Ignorer les approbations de demandes de tirage obsolètes lorsque de nouveaux commits sont poussés et/ou Demander l’approbation de la poussée révisable la plus récente, la création manuelle du commit de fusion pour une demande de tirage (pull request) et sa poussée (push) directement vers une branche protégée échouent, sauf si le contenu de la fusion correspond exactement à la fusion générée par GitHub pour la demande de tirage.

    En outre, avec ces paramètres, l’approbation des révisions est ignorée comme obsolète si la base de fusion introduit de nouvelles modifications après l’envoi de la révision. La base de fusion est le commit qui est le dernier ancêtre commun entre la branche de rubrique et le branche de base. Si la base de fusion change, la demande de tirage ne peut pas être fusionnée tant que quelqu’un n’a pas approuvé à nouveau le travail.

    • Sous « Protéger les branches correspondantes », sélectionnez Exiger une demande de tirage avant de fusionner.

    • Pour demander des approbations avant la fusion d’une demande de tirage, sélectionnez Demander des approbations.

      Sélectionnez le menu déroulant Nombre d’approbations nécessaires avant la fusion, puis sélectionnez le nombre de révisions d’approbation que vous souhaitez demander sur la branche.

    • Si vous le souhaitez, pour ignorer une révision d’approbation de demande de tirage lorsqu’un commit de modification de code est poussé vers la branche, sélectionnez Ignorer les approbations de demandes de tirage obsolètes lorsque de nouveaux commits sont poussés.

    • Si vous le souhaitez, pour exiger une révision de la part d’un propriétaire de code lorsque la demande de tirage affecte du code qui a un propriétaire désigné, sélectionnez Exiger une révision de la part des propriétaires de code. Notez que si le code a plusieurs propriétaires, l’approbation de n’importe lequel d’entre eux sera suffisante pour satisfaire à cette exigence. Pour plus d’informations, consultez « À propos des propriétaires de code ».

    • Si vous le souhaitez, pour autoriser des acteurs spécifiques à pousser du code vers la branche sans créer de demandes de tirage lorsqu’elles sont exigées, sélectionnez Autoriser les acteurs spécifiés à contourner les demandes de tirage requises. Ensuite, recherchez et sélectionnez les acteurs qui doivent être autorisés à ignorer la création d’une demande de tirage.

    • Si vous le souhaitez, si le dépôt fait partie d’une organisation, sélectionnez Restreindre qui peut ignorer les révisions de demandes de tirage. Ensuite, dans le champ de recherche, recherchez et sélectionnez les acteurs autorisés à ignorer les révisions de demandes de tirage. Pour plus d’informations, consultez « Ignorer la révision d’une demande de tirage ».

    • Si vous le souhaitez, pour demander à une personne autre que la dernière personne à pousser vers une branche d’approuver une demande de tirage avant la fusion, sélectionnez Demander l’approbation de la poussée révisable la plus récente. Pour plus d’informations, consultez « À propos des branches protégées ».

  7. Si vous le souhaitez, activez les vérifications d’état requises. Pour plus d’informations, consultez « À propos des vérifications d’état ».

    • Sélectionnez Exiger la réussite des vérifications d’état avant de fusionner.
    • Si vous le souhaitez, pour être sûr que les demandes de tirage sont testées avec le code le plus récent de la branche protégée, sélectionnez Exiger que les branches soient à jour avant la fusion.
    • Dans le champ de recherche, recherchez les vérifications d’état, en sélectionnant celles que vous souhaitez exiger.
  8. Si vous le souhaitez, sélectionnez Exiger une résolution de conversation avant de fusionner.

  9. Si vous le souhaitez, sélectionnez Exiger des commits signés.

  10. Si vous le souhaitez, sélectionnez Exiger un historique linéaire.

  11. Si vous le souhaitez, pour fusionner des demandes de tirage à l’aide d’une file d’attente de fusion, sélectionnez Exiger une file d’attente de fusion. Pour plus d’informations sur les files d’attente de fusion, consultez « Gestion d’une file d’attente de fusion ».

  12. Si vous le souhaitez, pour choisir les environnements sur lesquels les modifications doivent être correctement déployées avant la fusion, sélectionnez Exiger la réussite des déploiements avant de fusionner, puis sélectionnez les environnements.

  13. Vous pouvez aussi définir la branche en lecture seule.

    • Sélectionnez Verrouiller la branche.
    • Si vous le souhaitez, pour autoriser la synchronisation de la duplication, sélectionnez Autoriser la synchronisation de la duplication.
  14. Si vous le souhaitez, sélectionnez Ne pas autoriser le contournement des paramètres ci-dessus.

  15. Si vous le souhaitez, activez les restrictions de branche.

    • Sélectionnez Restreindre qui peut effectuer un push vers les branches correspondantes.
    • Si vous le souhaitez, pour restreindre également la création de branches correspondantes, sélectionnez Restreindre les poussées qui créent des branches correspondantes.
    • Dans le champ de recherche, recherchez et sélectionnez les personnes, équipes ou applications qui auront l’autorisation de pousser vers la branche protégée ou de créer une branche correspondante.
  16. Si vous le souhaitez, sous « Règles appliquées à tous, y compris les administrateurs », sélectionnez Autoriser les poussées de force.

    Ensuite, choisissez ensuite qui peut forcer la poussée vers la branche.

    • Sélectionnez Tout le monde pour autoriser toute personne ayant au moins des autorisations d’écriture dans le dépôt à forcer la poussée vers la branche, y compris celles disposant d’autorisations d’administrateur.
    • Sélectionnez Spécifier qui peut forcer la poussée pour autoriser uniquement des acteurs spécifiques à forcer la poussée vers la branche. Ensuite, recherchez et sélectionnez ces acteurs.

    Pour plus d’informations sur les poussées de force, consultez « À propos des branches protégées ».

  17. Si vous le souhaitez, sélectionnez Autoriser les suppressions.

  18. Cliquez sur Créer.

Modification d’une règle de protection de branche

  1. Sur GitHub, accédez à la page principale du référentiel.

  2. Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.

    Capture d’écran d’un en-tête de dépôt montrant les onglets. L’onglet « Paramètres » est mis en évidence avec un encadré orange foncé.

  3. Dans la section « Code et automatisation » de la barre latérale, cliquez sur Branches.

  4. À droite de la règle de protection de branche que vous souhaitez modifier, cliquez sur Modifier.

  5. Apportez vos modifications souhaitées à la règle de protection de branche.

  6. Cliquez sur Save changes.

Suppression d’une règle de protection de branche

  1. Sur GitHub, accédez à la page principale du référentiel.

  2. Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.

    Capture d’écran d’un en-tête de dépôt montrant les onglets. L’onglet « Paramètres » est mis en évidence avec un encadré orange foncé.

  3. Dans la section « Code et automatisation » de la barre latérale, cliquez sur Branches.

  4. À droite de la règle de protection de branche que vous souhaitez supprimer, cliquez sur Supprimer.