Bloquer les fusions non conformes

Une proposition de fusion peut respecter les conventions de l’équipe tout en restant risquée si la plateforme permet de l’intégrer malgré un contrôle en échec ou sans revue. Vous allez transformer ces exigences en règles appliquées par le dépôt, plutôt qu’en simples consignes à suivre manuellement. Les intitulés et l’emplacement des réglages varient selon le service Git ; recherchez les paramètres de protection de branche ou de règles de branche.

Cibler la bonne branche et le bon périmètre

Dans les paramètres du dépôt, créez une règle qui cible précisément la branche principale utilisée par l’équipe, par exemple main si c’est bien son nom dans votre dépôt. Vérifiez le motif de branche : une règle trop large peut affecter des branches de maintenance, tandis qu’une règle trop étroite peut ne protéger aucune branche. Appliquez-la à la branche existante et aux futures branches qui correspondent au motif, si le service propose cette option.

Une règle de protection de branche est un ensemble de conditions que la plateforme vérifie avant d’accepter une opération sur la branche ciblée. Elle peut notamment interdire les mises à jour directes, imposer le passage par une proposition de fusion et bloquer certaines opérations destructrices. La stratégie d’intégration linéaire et la protection de la branche principale ont été définies dans la leçon « Fixer les règles de fusion et d’historique » ; ici, vous rendez ces décisions contraignantes.

Exiger les contrôles et la revue

Activez l’option qui exige que les contrôles de statut passent avant la fusion. Sélectionnez les contrôles réellement configurés dans l’intégration continue, en vous appuyant sur les noms exacts affichés par une exécution réussie sur une proposition de fusion. Le service peut afficher un nom de vérification, un nom de tâche ou une combinaison des deux ; choisissez le statut produit par le pipeline attendu, pas une vérification homonyme ou ancienne.

Exigez ensuite une proposition de fusion et le nombre minimal d’approbations défini par l’équipe. Pour un dépôt où une seconde personne doit vérifier chaque changement, réglez ce seuil à une approbation ; une équipe plus sensible ou plus large peut fixer un seuil supérieur. Vérifiez aussi si les auteurs peuvent approuver leur propre proposition : pour que l’approbation constitue une revue indépendante, désactivez cette possibilité lorsque le service le permet.

Activez, si elle existe, la règle qui invalide les approbations lorsque de nouveaux commits sont ajoutés à la proposition. Sans cette précaution, une approbation donnée pour un état du code peut rester valable après une modification importante que la personne n’a pas examinée. Selon la plateforme, vous pouvez aussi exiger la résolution des discussions de revue ; n’activez cette option que si l’équipe traite effectivement ces discussions dans le même processus.

Empêcher les modifications qui contournent le processus

Interdisez les mises à jour forcées de la branche protégée et sa suppression. Une mise à jour forcée peut remplacer son historique au lieu d’ajouter des commits ; une suppression rend la branche principale indisponible jusqu’à sa recréation. Les changements doivent donc passer par le mécanisme contrôlé de proposition de fusion, et non par une opération directe qui contourne les contrôles.

Examinez attentivement les options de contournement : certains services permettent aux administrateurs ou à des rôles particuliers d’ignorer les règles. Réduisez cette liste aux personnes qui ont une responsabilité opérationnelle réelle et vérifiez que les opérations de contournement sont traçables. Si le service permet de désactiver totalement le contournement, retenez cette option lorsque l’organisation peut fonctionner sans exception ; sinon, documentez qui peut intervenir et dans quelles circonstances.

Tester les règles avant de les considérer actives

Enregistrez la règle, puis vérifiez son comportement sur une proposition de fusion de test ou sur une contribution à faible risque. Tant qu’un contrôle requis n’a pas réussi ou que l’approbation manque, l’interface doit refuser la fusion ou indiquer explicitement qu’elle est bloquée. Après réussite des contrôles et obtention de l’approbation, la fusion doit devenir possible sans désactiver la protection.

Contrôlez enfin les réglages effectifs : branche ciblée, statuts obligatoires, seuil d’approbation, règles d’obsolescence des approbations, interdiction des mises à jour forcées et de la suppression, personnes autorisées à contourner les règles. Si une proposition reste bloquée alors que ses contrôles semblent réussis, comparez le nom du statut exigé avec celui réellement publié par le pipeline. Les contrôles et leur statut dans l’intégration continue ont été présentés dans « Exécuter les contrôles dans une intégration continue ».

À retenir

• Ciblez exactement la branche principale et vérifiez la portée de la règle.
• Exigez les statuts de contrôle effectivement publiés par le pipeline et le nombre d’approbations décidé par l’équipe.
• Réinitialisez les approbations après de nouveaux commits lorsque le service le permet.
• Bloquez les mises à jour forcées et la suppression de la branche protégée.
• Limitez les exceptions et testez qu’une proposition non conforme est réellement bloquée.

La prochaine étape consiste à mettre ces conventions à l’épreuve sur le dépôt du site, en préparant des critères d’acceptation vérifiables pour l’équipe.