Doelbranches configureren voor pull-aanvragen

Azure DevOps Services

Standaard stelt Azure DevOps voor om nieuwe pull-verzoeken aan te maken tegen 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.

Vereiste voorwaarden

Wanneer wordt deze configuratie gebruikt?

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

• Suggesties voor pull-aanvragen. Wanneer een gebruiker een vertakking naar Azure DevOps pusht, kan hun volgende bezoek aan de Repos-pagina suggereren om een pull request 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.

• Vervolgkeuzelijst vertakking. Wanneer een gebruiker de vervolgkeuzelijst voor vertakkingen opent in Azure DevOps, worden vertakkingen die zijn opgegeven in de pull request-doelen weergegeven in een sectie met de naam 'Doelen', tussen de secties 'Mijn' en 'Alle'.

  

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 zijn beschermd door pull requestbeleid. 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 de tweede ouder de commits die worden geïntroduceerd in de doelvertakking door het voltooien van een pull request, en de eerste ouder is de vorige top van de tak.

Hoe kiest Azure DevOps een vertakking?

Git houdt geen metagegevens bij bij het aanmaken van een branch. Er is geen exacte manier om te bepalen welke vertakking is gebruikt bij het maken van een onderwerptak. In plaats daarvan gebruikt Azure DevOps een heuristiek op basis van de eerst-bovenliggende geschiedenis van de takken.

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

Voorbeeld: Geen samenvoegdoorvoeringen

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

  ,-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 bronvertakking, topic, wordt vervolgens vergeleken met deze vertakkingen.

• main snijdt topic bij B, waarbij G,I in topic blijft en niet in main.
• release/2024-September doorkruist topic bij A, waarbij B,G,I in topic achterblijft en niet in release/2024-September.
• feature/targets snijdt topic bij G, waarbij I in topic blijft en niet in feature/targets.

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

Voorbeeld: Commits samenvoegen

In een complexer voorbeeld, waarbij de feature/targets vertakking is samengevoegd met main en main met zichzelf is samengevoegd, heeft de commitgeschiedenis meer aspecten 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 Dmain een tijd waarin feature/targets is samengevoegd in main. Commit M geeft het moment aan waarop main werd samengevoegd in 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 in overweging neemt, kruisen main en feature/targets beide de geschiedenis van topic bij G. De eerste oudergeschiedenis toont echter nog steeds een voorkeur voor feature/targets.

Belangrijke banden

Als twee vertakkingen hetzelfde snijpunt voor de eerste bovenliggende historie hebben, selecteert Azure DevOps de vertakking die eerder in de pull_request_targets lijst wordt weergegeven. Als er nog steeds meerdere branches gelijk staan op basis van de pull_request_targets lijst vanwege een overeenkomst met voorvoegsels, is de eerste in alfabetische volgorde de winnaar.

Dit soort verbindingen zijn meestal aanwezig wanneer nieuwe kandidaat-vertakkingen worden gemaakt, zoals het begin van een nieuwe featurevertakking of de afsplitsing van een releasevertakking.

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

In dit voorbeeld is de release/2024-October tak gemaakt van de main tak nadat de topic tak afgesplitst is van main. 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 aanmaken van pull requests heeft een keuzelijst om de doelvertakking aan te passen als de dynamische keuze niet voldoet aan de verwachtingen. 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 targetbranches en de bronbranch zijn gemaakt. Hier volgen enkele mogelijke redenen waarom de heuristiek niet werkt:

• De doelbranches worden niet beschermd door pull request-beleidsregels. Als de doelbranches willekeurig kunnen worden gepusht, is de eerste-oudergeschiedenis geen betrouwbare indicator van de vorige locatie van die branch.

• 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 de opdracht git rebase wordt de geschiedenis van de eerste ouder herschreven zodat de heuristiek het nieuwe doel kiest.

Een veelvoorkomende fout die gebruikers maken wanneer ze beseffen dat ze zich op de verkeerde vertakking bevinden, is om git merge te gebruiken om de juiste vertakking aan hun geschiedenis toe te voegen. Bij het samenvoegen wordt de geschiedenis van de eerste ouder niet gewijzigd, en daardoor verandert de keuze voor de doelvertakking niet.

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 u eerst git fetch origin 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

Verwante artikelen:

• De standaardbranch wijzigen
• Pull-aanvragen maken
• Pull-aanvragen weergeven
• Pull-aanvragen controleren
• Pull-aanvragen voltooien
• Meerdere samenvoegingsbasissen