Partager via

Configurer les branches cibles pour les demandes d’extraction

  • Article

Azure DevOps Services

Par défaut, Azure DevOps suggère la création de nouvelles demandes de tirage sur le branche par défaut. Dans un référentiel avec plusieurs branches utilisées pour les demandes de tirage, les propriétaires de référentiels peuvent configurer la liste des branches cibles de demande de tirage afin que ces suggestions sélectionnent la branche cible appropriée.

Pour activer cette fonctionnalité, créez un fichier avec un nom .azuredevops/pull_request_targets.yml dans le branche par défaut du référentiel. Ce fichier YAML doit contenir une seule liste, intitulée pull_request_targets, contenant les noms de branche ou les préfixes qui correspondent aux branches candidates.

Par exemple, tenez compte de ce contenu :

pull_request_targets:
  - main
  - release/*
  - feature/*

Cette liste de cibles potentielles spécifie main en tant que branche cible à sélectionner en premier, mais si une branche commençant release/ par ou feature/ est un meilleur choix, cette branche est choisie à la place.

Pour plus d’instructions sur les demandes de tirage et les considérations de gestion, consultez À propos des demandes de tirage.

Quand cette configuration est-elle utilisée ?

Il existe plusieurs points d’entrée à l’aide d’une branche cible dynamique.

  • Suggestions de demande de tirage. Lorsqu’un utilisateur envoie une branche à Azure DevOps, sa prochaine visite à la page Repos peut suggérer la création d’une demande de tirage à partir de cette branche. Ce bouton « Créer une demande de tirage » choisit la branche cible de manière dynamique.

  • URL de la demande de tirage( Pull Request). Lorsqu’un utilisateur accède directement à la page de création de demande de tirage à l’aide d’un sourceRef paramètre, mais omettez le targetRef paramètre, Azure DevOps sélectionne une branche cible en fonction de ce choix dynamique.

Il existe une fonctionnalité permettant aux outils clients de créer des demandes de tirage à l’aide de ce choix dynamique, mais ces clients doivent ajouter un signal facultatif indiquant que l’utilisateur n’a pas spécifié de branche cible. Vérifiez l’outil client de votre choix pour voir si l’option est activée.

Quels sont les bons candidats pour les cibles de branche ?

Nous recommandons que la liste configurée des branches candidates inclut uniquement les branches protégées par les stratégies de demande de tirage. Ces branches sont probablement modifiées uniquement en effectuant des demandes de tirage, ce qui garantit que la position de branche précédente se trouve dans l’historique du premier parent de la validation du pourboire. Si une stratégie de fusion est utilisée, le deuxième parent représente les validations introduites dans la branche cible en effectuant une demande de tirage et le premier parent est le conseil précédent.

Comment Azure DevOps sélectionne-t-il une branche ?

Git ne suit pas les métadonnées autour de la création d’une branche. Il n’existe aucun moyen exact de déterminer quelle branche a été utilisée lors de la création d’une branche de rubrique. Au lieu de cela, Azure DevOps utilise une heuristique basée sur l’historique du premier parent des branches.

Parmi les branches cibles possibles, Azure DevOps sélectionne la branche dont l’historique du premier parent se croise avec l’historique du premier parent de la branche source le plus.

Exemple : Aucune validation de fusion

Considérez la structure de branche suivante, qui est simplifiée plus que normale, car il n’y a pas de validations de fusion. Dans cet exemple, l’historique entier est représenté par l’historique du premier parent.

  ,-E---F <-- release/2024-September
 /
A---B---C---D <--- main
     \
      `-G---H <--- feature/targets
         \
          `-I <--- topic

Avec cet historique et l’exemple pull_request_targets de liste utilisé précédemment, nous avons trois branches cibles candidates, par ordre de priorité :

  • main
  • release/2024-September
  • feature/targets

La branche source, topicest ensuite comparée à ces branches.

  • main croise avec topic à , Blaissant G,I dans topic et non dans main.
  • release/2024-September croise avec topic le A départ B,G,I et topic non dans release/2024-September.
  • feature/targets croise avec topic à , Glaissant I dans topic et non dans feature/targets.

Par conséquent, dans cet exemple, la feature/targets branche est choisie comme branche cible pour une demande de tirage avec topic comme branche source.

Exemple : validations de fusion

Dans un exemple plus compliqué, où la feature/targets branche a été fusionnée main et fusionnée main en elle-même, l’historique des validations comporte plus de cas à prendre en compte :

  ,-E---F <-- release/2024-September
 /
A---B---C---D---J---K <--- main
     \    _/     \
      \  /        \
       `G---H---L--\--M <--- feature/targets
         \          \/
          \
           `I <--- topic

Ici, la validation D main représente une heure où feature/targets a été fusionnée dans main. La validation M représente une heure dans laquelle main a été fusionnée feature/targets. Le lien entre les validations M et J est dessiné de manière à souligner qu’il J s’agit du deuxième parent du M L premier parent.

Dans ce cas, lorsque vous considérez l’historique de validation complet, main et que vous croisez tous les deux l’historique de l’at topic G.feature/targets Toutefois, le premier historique parent illustre toujours une préférence pour feature/targets.

Liens cassants

Si deux branches ont la même intersection d’historique parent, Azure Devops sélectionne la branche qui apparaît précédemment dans la pull_request_targets liste. Si plusieurs branches sont toujours liées en fonction de la pull_request_targets liste en raison d’une correspondance de préfixe, le plus tôt dans l’ordre alphabétique gagne.

Ces types de liens sont le plus souvent présents lorsque de nouvelles branches candidates sont créées, telles que le début d’une nouvelle branche de fonctionnalité ou la fourche d’une branche de mise en production.

          ,-E---F <-- release/2024-October
         /
A---B---C---D <--- main
     \
      \
       `G <--- topic

Dans cet exemple, la release/2024-October branche a été créée hors de la main branche après topic avoir été ramifiée de main. Bien que cela soit intuitif pour un lecteur humain, l’ordre des catégories et release/* des main catégories dans la pull_request_targets liste indique l’ordre préféré à Azure DevOps.

Que se passe-t-il si Azure DevOps choisit la branche cible incorrecte ?

La page de création de demande de tirage a un sélecteur pour ajuster la branche cible si le choix dynamique ne correspond pas aux attentes. La branche cible peut également être ajustée une fois la demande de tirage créée.

Plus important encore, il peut être utile de comprendre pourquoi l’heuristique peut sélectionner la branche cible « incorrecte ».

Cette heuristique s’appuie sur certaines hypothèses sur la façon dont les branches cibles et la branche source ont été créées. Voici quelques raisons potentielles pour lesquelles l’heuristique ne fonctionne pas :

  • Les branches cibles ne sont pas protégées par les stratégies de demande de tirage. Si les branches cibles peuvent être envoyées arbitrairement, l’historique du premier parent n’est pas un indicateur fiable de l’emplacement précédent de cette branche.

  • La branche source a été créée à partir d’un conseil précédent d’une branche candidate. Si la branche source a choisi une validation arbitraire dans l’historique, il n’existe aucune garantie sur le premier historique parent dont elle dépend.

  • La branche source a été avancée à l’aide git commit et git merge aux commandes. Les commandes telles que git reset --hard ou git rebase peuvent modifier l’historique de la branche de manière imprévisible.

Si vous n’êtes pas d’accord avec la branche cible choisie par cette heuristique, envisagez de mettre à jour le choix à l’aide git rebase --onto <new-target> <old-target> <source>de . La git rebase commande réécrit l’historique du premier parent pour que l’heuristique choisisse la nouvelle cible.

Une erreur courante que les utilisateurs font quand ils se rendent compte qu’ils sont basés sur la branche incorrecte consiste à utiliser git merge pour amener la branche appropriée dans leur historique. La fusion ne modifie pas l’historique du premier parent et ne modifie donc pas le choix de la branche cible.

Comment puis-je tester cette décision localement ?

L’heuristique utilisée par Azure DevOps a été contribué au client Git principal et est disponible dans les versions 2.47.0 et ultérieures de Git.

Pour tester cette logique dans votre propre référentiel, commencez par vous git fetch origin assurer que vous disposez de la dernière version des branches cibles. Exécutez ensuite la commande suivante git for-each-ref , ajustée pour correspondre à votre liste de branches candidates :

$ git for-each-ref --format="%(is-base:HEAD) %(refname)" \
           refs/remotes/origin/main \
           "refs/remotes/origin/release/*" \
           "refs/remotes/origin/feature/*"
 refs/remotes/origin/main
 refs/remotes/origin/release/2024-September
(HEAD) refs/remotes/origin/feature/targets

Dans cette commande, la HEAD validation est utilisée comme source et compare l’historique du premier parent des branches cibles de la même façon. Bien que chaque branche candidate soit répertoriée dans la sortie, la chaîne (HEAD) indique quelles branches doivent être utilisées comme branche cible.

Étapes suivantes

Créer une demande de tirage (pull request) Vérifier les demandes de tirage (pull request)