Delen via

Doelbranches configureren voor pull-aanvragen

  • Artikel

Azure DevOps Services

Standaard wordt in Azure DevOps voorgesteld om nieuwe pull-aanvragen te maken op basis van de standaardbranch. In een opslagplaats met meerdere vertakkingen die worden gebruikt voor pull-aanvragen, kunnen eigenaren van opslagplaatsen de lijst met doelbranches voor pull-aanvragen configureren, zodat deze suggesties de juiste doelbranch selecteren.

Als u deze functie wilt inschakelen, maakt u een bestand met de naam .azuredevops/pull_request_targets.yml in de standaardbranch van de opslagplaats. Dit YAML-bestand moet één lijst met de titel pull_request_targetsbevatten, met de vertakkingsnamen of voorvoegsels die overeenkomen met de kandidaatvertakkingen.

Denk bijvoorbeeld aan de volgende inhoud:

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

Deze lijst met potentiële doelen geeft aan main als de doelvertakking om eerst te selecteren, maar als een vertakking begint met release/ of feature/ een betere keuze is, wordt die vertakking in plaats daarvan gekozen.

Zie Over pull-aanvragen voor meer richtlijnen en beheeroverwegingen voor pull-aanvragen.

Wanneer wordt deze configuratie gebruikt?

Er zijn meerdere toegangspunten voor het gebruik van een dynamische doelbranch.

  • Suggesties voor pull-aanvragen. Wanneer een gebruiker een vertakking naar Azure DevOps pusht, kan het volgende bezoek aan de pagina Opslagplaatsen voorstellen om een pull-aanvraag van die vertakking te maken. Met deze knop Nieuwe pull-aanvraag maken wordt de doelbranch dynamisch gekozen.

  • URL van pull-aanvraag. Wanneer een gebruiker rechtstreeks naar de pagina voor het maken van pull-aanvragen navigeert met behulp van een sourceRef parameter, maar de targetRef parameter weglaat, selecteert Azure DevOps een doelvertakking op basis van deze dynamische keuze.

Er is een mogelijkheid voor clienthulpprogramma's om pull-aanvragen te maken met behulp van deze dynamische keuze, maar die clients moeten een optioneel signaal toevoegen dat de gebruiker geen doelbranch heeft opgegeven. Controleer het clienthulpprogramma van uw keuze om te zien of de optie is ingeschakeld.

Wat zijn goede kandidaten voor vertakkingsdoelen?

Het is raadzaam dat de geconfigureerde lijst met kandidaat-vertakkingen alleen vertakkingen bevat die worden beveiligd door beleid voor pull-aanvragen. Dergelijke vertakkingen worden waarschijnlijk alleen gewijzigd door pull-aanvragen te voltooien, wat garandeert dat de vorige vertakkingspositie zich in de eerste bovenliggende geschiedenis van de doorvoering van de tip bevindt. Als een samenvoegstrategie wordt gebruikt, vertegenwoordigt het tweede bovenliggende item de doorvoeringen die worden geïntroduceerd in de doelvertakking door een pull-aanvraag te voltooien en de eerste bovenliggende is de vorige tip.

Hoe kiest Azure DevOps een vertakking?

Git houdt geen metagegevens bij rond het maken van een vertakking. Er is geen exacte manier om te bepalen welke vertakking is gebruikt bij het maken van een onderwerpbranch. In plaats daarvan gebruikt Azure DevOps een heuristiek op basis van de eerste bovenliggende geschiedenis van de vertakkingen.

Onder de mogelijke doelvertakkingen selecteert Azure DevOps de vertakking waarvan de eerste bovenliggende geschiedenis de eerste bovenliggende geschiedenis van de bronvertakking het meest doorkruist.

Voorbeeld: Geen samenvoegdoorvoeringen

Houd rekening met de volgende vertakkingsstructuur, die meer dan normaal is, omdat er geen samenvoegdoorvoeringen zijn. In dit voorbeeld wordt de hele geschiedenis weergegeven door de eerste bovenliggende geschiedenis.

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

Met deze geschiedenis en de voorbeeldlijst pull_request_targets die eerder is gebruikt, hebben we drie kandidaatdoeltakken, in volgorde van prioriteit:

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

De bronbranch, topicwordt vervolgens vergeleken met deze vertakkingen.

  • mainkruist met topic bij , weggaan G,I topic en niet in mainB.
  • release/2024-Septemberdoorkruist bij topic A het binnenlaten topic B,G,I en niet in release/2024-September.
  • feature/targetskruist met topic bij , weggaan I topic en niet in feature/targetsG.

Daarom wordt in dit voorbeeld de feature/targets vertakking gekozen als doelvertakking voor een pull-aanvraag met topic als bronvertakking.

Voorbeeld: Doorvoeringen samenvoegen

In een ingewikkelder voorbeeld, waarbij de feature/targets vertakking is samengevoegd main en main samengevoegd met zichzelf, heeft de doorvoergeschiedenis meer zaken om rekening mee te houden:

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

Hier vertegenwoordigt de doorvoering D main een tijd waarin feature/targets is samengevoegd in main. Doorvoer M vertegenwoordigt een tijd waarin main is samengevoegd.feature/targets De koppeling tussen doorvoeringen M en J wordt getekend op een manier om te benadrukken dat J het tweede bovenliggende element M van de L taak de eerste bovenliggende is.

In dit geval, wanneer u de volledige doorvoergeschiedenis beschouwt en feature/targets main beide de geschiedenis van topic op Gelkaar snijden. De eerste bovenliggende geschiedenis toont echter nog steeds een voorkeur voor feature/targets.

Belangrijke banden

Als twee vertakkingen hetzelfde snijpunt voor de eerste bovenliggende geschiedenis hebben, selecteert Azure Devops de vertakking die eerder in de pull_request_targets lijst wordt weergegeven. Als er nog steeds meerdere vertakkingen zijn gekoppeld op basis van de pull_request_targets lijst vanwege een overeenkomst met voorvoegsels, wint de vroegste in alfabetische volgorde.

Dit soort banden zijn meestal aanwezig wanneer nieuwe kandidaat-vertakkingen worden gemaakt, zoals het begin van een nieuwe functiebranch of de fork van een releasebranch.

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

In dit voorbeeld is de release/2024-October vertakking gemaakt van de vertakking nadat topic de main vertakking is mainuitgeschakeld. Hoewel dit intuïtief is voor een menselijke lezer, geeft de volgorde van de main en release/* categorieën in de pull_request_targets lijst de voorkeursvolgorde aan voor Azure DevOps.

Wat gebeurt er als Azure DevOps de verkeerde doelbranch kiest?

De pagina voor het maken van pull-aanvragen heeft een selector voor het aanpassen van de doelvertakking als de dynamische keuze niet aan de verwachtingen voldoet. De doelbranch kan ook worden aangepast nadat de pull-aanvraag is gemaakt.

Belangrijker is dat het waardevol is om te begrijpen waarom de heuristiek de 'verkeerde' doelvertakking selecteert.

Deze heuristiek is afhankelijk van enkele veronderstellingen over hoe de doeltakken en de bronbranch zijn gemaakt. Hier volgen enkele mogelijke redenen waarom de heuristiek niet werkt:

  • De doelbranches worden niet beveiligd door beleid voor pull-aanvragen. Als de doelvertakkingen willekeurig kunnen worden gepusht, is de eerste bovenliggende geschiedenis geen betrouwbare indicator van de vorige locatie van die vertakking.

  • De bronbranch is gemaakt op basis van een vorige tip van een kandidaatbranch. Als de bronbranch een willekeurige doorvoering in de geschiedenis heeft gekozen, is er geen garantie voor de eerste bovenliggende geschiedenis waarop deze afhankelijk is.

  • De bronbranch is geavanceerd met behulp van git commit en git merge opdrachten. Opdrachten zoals git reset --hard of git rebase kunnen de geschiedenis van de vertakking op onvoorspelbare manieren wijzigen.

Als u het niet eens bent met de doelvertakking die door deze heuristiek is gekozen, kunt u overwegen de keuze bij te werken met behulp van git rebase --onto <new-target> <old-target> <source>. Met git rebase de opdracht wordt de eerste bovenliggende geschiedenis herschreven om de heuristiek het nieuwe doel te kiezen.

Een veelvoorkomende fout die gebruikers maken bij het realiseren dat ze zijn gebaseerd op de verkeerde vertakking, is om git merge de juiste vertakking in hun geschiedenis te brengen. Bij samenvoegen wordt de eerste bovenliggende geschiedenis niet gewijzigd en wordt de keuze voor de doelvertakking dus niet gewijzigd.

Hoe kan ik deze beslissing lokaal testen?

De heuristiek die door Azure DevOps wordt gebruikt, is bijgedragen aan de git-kernclient en is beschikbaar in Git-versies 2.47.0 en hoger.

Als u deze logica in uw eigen opslagplaats wilt testen, voert git fetch origin u eerst uit om te controleren of u de nieuwste versie van de doelbranches hebt. Voer vervolgens de volgende git for-each-ref opdracht uit die is aangepast aan uw lijst met kandidaat-vertakkingen:

$ 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

In deze opdracht wordt de HEAD doorvoering gebruikt als bron en wordt de eerste bovenliggende geschiedenis van de doelvertakkingen op dezelfde manier vergeleken. Hoewel elke kandidaat-vertakking wordt vermeld in de uitvoer, geeft de tekenreeks (HEAD) aan welke van de vertakkingen moet worden gebruikt als de doelbranch.

Volgende stappen

Een pull-aanvraagcontroleren maken