Règles de protection des branches et révision des exigences
Les règles de protection des branches constituent l’un des mécanismes les plus importants pour appliquer des stratégies de collaboration sur GHES. Ils définissent les conditions qui doivent être remplies avant que les modifications puissent être fusionnées dans des branches protégées.
Dans cette unité, vous allez apprendre
Ce que contrôlent les règles de protection des branches
Comment les exigences de révision sont appliquées
Comment ces règles affectent les flux de travail de développement quotidiens
Quelles sont les règles de protection des branches appliquées ?
Les règles de protection des branches spécifient la façon dont les modifications circulent dans des branches importantes, en particulier la branche par défaut. Dans GitHub Enterprise Server, ces règles nécessitent généralement que toutes les modifications soient fusionnées via des pull requests plutôt que des envois push directs. Les organisations nécessitent souvent un nombre minimal d’approbations et appliquent des vérifications d’état automatisées, telles que des builds ou des tests, avant d’autoriser une fusion.
Des protections supplémentaires peuvent empêcher les push forcés, restreindre qui peut fusionner les modifications ou bloquer la suppression de branches. Ensemble, ces paramètres garantissent que les branches protégées restent stables, traceables et conformes aux normes d’entreprise.
Les organisations peuvent également exiger une révision des propriétaires de code pour des chemins spécifiques, exiger la résolution des conversations avant la fusion, appliquer une méthode de fusion spécifique (telle que la fusion par compression) ou exiger un historique de validation linéaire. Certaines entreprises limitent également les personnes autorisées à pousser dans les branches protégées, même par le biais de pull requests, pour s’assurer que seuls les rôles approuvés peuvent réaliser des fusions.
Ensembles de règles de dépôt : politique à grande échelle
En plus des règles de protection de branche traditionnelles, GitHub Enterprise Server prend en charge les ensembles de règles de référentiel. Les ensembles de règles permettent aux administrateurs d’appliquer des stratégies entre plusieurs branches ou référentiels à partir d’un emplacement centralisé.
Bien que la protection des branches s’applique à des branches individuelles, les ensembles de règles peuvent cibler des modèles de branche ou des référentiels entiers. Ils peuvent exiger des pull requests, appliquer des vérifications de statut, restreindre les push forcés, exiger un historique linéaire et des approbations.
La principale différence est la centralisation. Les stratégies sont définies une fois et appliquées de manière cohérente, ce qui réduit la dérive de configuration entre les référentiels. Pour les développeurs, l’effet est le même : les fusions sont bloquées jusqu’à ce que les exigences soient remplies, mais ces exigences peuvent désormais être appliquées à l’échelle de l’entreprise.
Les ensembles de règles de référentiel centralisent et normalisent la gouvernance entre les référentiels.
Passer en revue les exigences en tant que contrôles de gouvernance
Dans les environnements d’entreprise, les révisions de code ne sont pas seulement des bonnes pratiques ; ils sont des contrôles formels. Les exigences de révision peuvent inclure l’approbation des propriétaires de code désignés, le rejet des approbations lorsque de nouvelles modifications sont envoyées ou l’application de validations signées.
Ces exigences garantissent que les bonnes personnes examinent les bonnes modifications et que les approbations reflètent l’état final du code. Les révisions font partie de la piste d’audit de l’organisation, démontrant que les modifications ont été évaluées et approuvées en fonction de la stratégie.
Expérience du développeur avec les branches protégées
Pour les développeurs, les règles de protection des branches définissent les limites des flux de travail acceptables. Les fusions peuvent être bloquées jusqu’à ce que toutes les exigences soient satisfaites et que les règles de contournement ne soient généralement pas possibles. Bien que cela puisse ralentir les changements urgents, il réduit également le risque d’erreurs et fournit une confiance que le code fusionné répond aux normes organisationnelles.
Les développeurs efficaces planifient leur travail avec ces règles à l’esprit, ce qui permet de prendre du temps pour les révisions et les vérifications plutôt que de les traiter comme des obstacles.
En guise d’habitude pratique, les développeurs doivent traiter la protection des branches comme une liste de contrôle : ouvrez la pull request tôt, confirmez les réviseurs requis (y compris les propriétaires de code), surveillez les contrôles de statut et sachez que les nouveaux commits peuvent réinitialiser les approbations en fonction de la politique.
La planification de ces étapes réduit les retards de dernière minute.
Si la fusion est bloquée, utilisez les détails de la pull request pour identifier exactement quelle exigence n’est pas satisfaite (par exemple, approbations manquantes, conversations non résolues ou contrôles de statut échoués) avant de demander de l'aide à d'autres.
File d’attente de branche (file d’attente de fusion) pour l’intégration stable
Dans les dépôts à forte activité, les pull requests qui passent individuellement les vérifications peuvent toujours casser la branche par défaut lorsqu’elles sont fusionnées simultanément. La file d’attente de branche (file d’attente de fusion) réduit ce risque en validant les pull requests dans l’ordre de fusion.
Lorsque la fonctionnalité est activée, les pull requests approuvées entrent dans une file d'attente au lieu de fusionner immédiatement. Chaque pull request est validée par rapport à l’état le plus récent de la branche de base avant la fusion. Si les vérifications requises échouent pendant la validation, le pull request est supprimé de la file d’attente jusqu’à ce qu’il soit corrigé.
La file d’attente de branche permet de maintenir une branche par défaut stable de manière cohérente. Les développeurs peuvent rencontrer des temps d’attente de fusion plus longs, mais gagner en prévisibilité et moins d’échecs d’intégration.
La file d’attente de la branche améliore la stabilité de la branche en validant les requêtes d’extraction séquentiellement avant la fusion.
Étape par étape : identifier la raison pour laquelle une fusion est bloquée
Lorsqu’une pull request ne peut pas être fusionnée, les règles de protection de la branche indiquent généralement quelle exigence n’est pas satisfaite.
Ouvrez la pull request dans l’interface utilisateur Web de GHES.
Dans la section de fusion, identifiez la raison de blocage (par exemple, les approbations manquantes ou les vérifications ayant échoué).
Vérifiez les exigences de révision :
- Les réviseurs requis sont-ils affectés ?
- Les approbations CODEOWNERS sont-elles requises pour les fichiers que vous avez modifiés ?
- Les approbations ont-elles été révoquées en raison de nouveaux commits ?
Vérifiez les vérifications :
- Quelles vérifications requises échouent ?
- Des vérifications sont-elles toujours en attente parce que les exécuteurs ne sont pas disponibles ou en file d’attente ?
Vérifiez les exigences de conversation et de stratégie :
- Les conversations de révision doivent-elles être résolues ?
- Une méthode de fusion spécifique est-elle requise (squash/merge/rebase) ?
Apportez la plus petite modification nécessaire pour satisfaire à l’exigence manquante (corrigez l’échec de la vérification, demandez la révision requise ou résolvez les modifications demandées), puis réexétez l’éligibilité de fusion.
Si vous ne pouvez toujours pas déterminer la raison, incluez le message de blocage de fusion et la liste des vérifications/réviseurs requis lors de la demande d’aide.
Principaux points à prendre : les règles de protection des branches traduisent la stratégie d’entreprise en exigences de flux de travail quotidiennes et la collaboration réussie dépend de la conformité cohérente de ces exigences.
Une fois que vous comprenez quelles stratégies sont appliquées au niveau de la branche, l’étape suivante consiste à voir comment les pull requests rassemblent les révisions, les vérifications et les discussions en un flux de travail de modification unique.