Over pull-aanvragen
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Pull-aanvragen (PULL's) zijn een manier om code te wijzigen, te controleren en samen te voegen in een Git-opslagplaats in Azure-opslagplaatsen. PULL's kunnen afkomstig zijn van vertakkingen in dezelfde opslagplaats of van vertakkingen in forks van de opslagplaats. Teams gebruiken PULL's om code te controleren en feedback te geven over wijzigingen voordat de code wordt samengevoegd in de hoofdbranch. Revisoren kunnen de voorgestelde wijzigingen doorlopen, opmerkingen achterlaten en stemmen om de code goed te keuren of af te wijzen.
In dit artikel worden richtlijnen en beheeroverwegingen voor pull-aanvragen beschreven. Zie de volgende artikelen voor instructies voor het maken, weergeven, controleren en voltooien van pull-aanvragen:
- Pull-aanvragen maken
- Pull-aanvragen weergeven en openen
- Pull-aanvragen controleren
- Pull-aanvragen voltooien
Notitie
Om prestatie- en stabiliteitsredenen moet het aantal revisoren dat kan worden toegevoegd aan een pull-aanvraag 1000 of minder zijn. Nieuwe pull-aanvragen worden niet gemaakt bij het toevoegen van meer dan 1000 revisoren en bestaande pull-aanvragen bieden u niet de mogelijkheid om meer dan 1000 revisoren toe te voegen.
Machtigingen en vereisten
Opslagplaatsen moeten zijn ingeschakeld voor uw project. Als de opslagplaatshub en de bijbehorende pagina's niet worden weergegeven, raadpleegt u Een Azure DevOps-service in- of uitschakelen om opslagplaatsen opnieuw in of uit te schakelen.
Als u PULL's wilt weergeven of bekijken, moet u lid zijn van een Azure DevOps-project met basic-toegang of hoger.
- Als u geen project hebt, maakt u er een of meldt u zich gratis aan.
- Als u geen projectlid bent, wordt u toegevoegd.
Als u wilt bijdragen aan een pull-aanvraag, moet u lid zijn van de beveiligingsgroep Lezers of de bijbehorende machtigingen hebben.
Als u een pull-aanvraag wilt maken en voltooien, moet u lid zijn van de beveiligingsgroep Inzenders of de bijbehorende machtigingen hebben.
Notitie
Voor openbare projecten hebben gebruikers aan belanghebbenden volledige toegang tot Azure-opslagplaatsen.
- Opslagplaatsen moeten zijn ingeschakeld voor uw project. Als de opslagplaatshub en de bijbehorende pagina's niet worden weergegeven, raadpleegt u Een Azure DevOps-service in- of uitschakelen om opslagplaatsen opnieuw in of uit te schakelen.
- Als u PULL's wilt weergeven of bekijken, moet u lid zijn van een Azure DevOps-project met basic-toegang of hoger. Als u geen projectlid bent, wordt u toegevoegd.
- Als u wilt bijdragen aan een pull-aanvraag, moet u lid zijn van de beveiligingsgroep Lezers of de bijbehorende machtigingen hebben.
- Als u een pull-aanvraag wilt maken en voltooien, moet u lid zijn van de beveiligingsgroep Inzenders of de bijbehorende machtigingen hebben.
Zie Standaardmachtigingen en vertakkingsmachtigingen voor Git voor meer informatie over machtigingen en toegangsniveaus.
Kwaliteitsfeedback voor pull-aanvragen
Beoordelingen van hoge kwaliteit beginnen met feedback van hoge kwaliteit. Hier volgen enkele sleutels voor geweldige feedback over pull-aanvragen:
- De eigenaar van de pull-aanvraag moet de juiste personen hebben om de pull-aanvraag te controleren en ervoor te zorgen dat revisoren weten wat de code doet.
- Revisoren moeten bruikbare, constructieve feedback geven.
- Eigenaren en revisoren moeten snel opmerkingen maken en beantwoorden.
Pr-eigenaren moeten:
- Zorg ervoor dat u de juiste revisoren selecteert die u wilt toewijzen aan een pull-aanvraag.
- Neem revisoren op die weten hoe de code werkt.
- Vraag ontwikkelaars die op andere gebieden werken om hun ideeën te delen.
- Geef een duidelijke beschrijving van wijzigingen.
- Geef richtlijnen voor revisoren met pull-aanvraagsjablonen.
- Geef een build van de code op met de oplossing of functie die erin wordt uitgevoerd.
- Reageer op opmerkingen, accepteer de suggestie of leg uit waarom de voorgestelde wijziging niet ideaal is.
- Voor goede suggesties buiten het bereik van de pull-aanvraag maakt u nieuwe werkitems, vertakkingen en PULL's om deze wijzigingen aan te brengen.
Revisoren moeten de volgende taken uitvoeren.
- Feedback geven over wijzigingen waarmee ze het niet eens zijn
- Problemen identificeren en specifieke suggesties geven over wat u anders moet doen
- Zorg ervoor dat de feedback een duidelijke intentie heeft en gemakkelijk te begrijpen is
- Opmerkingen achterlaten of stemmen op wijzigingen
Zie Feedback ontvangen met Git-pull-aanvragen voor meer informatie.
Vertakkingsbeleid en pull-aanvragen
Uw team kan afhankelijk zijn van kritieke vertakkingen in uw opslagplaats, zoals de main
vertakking, om altijd in goede vorm te zijn. U kunt vertakkingsbeleid instellen om pull-aanvragen te vereisen voor wijzigingen in deze beveiligde vertakkingen en eventuele wijzigingen die rechtstreeks naar de vertakkingen worden gepusht, af te wijzen.
U kunt meer beleidsregels toevoegen aan PULL's om betere codekwaliteit in belangrijke vertakkingen af te dwingen. Extra vereisten, zoals een schone build van de voorgestelde code of goedkeuring van meerdere revisoren, kunnen helpen bij het beveiligen van belangrijke vertakkingen.
U kunt het aantal vereiste goedkeuringen voor een pull-aanvraag instellen in een vertakkingsbeleid. U kunt ook instellen dat bepaalde revisoren vereist of optioneel zijn voor alle of bepaalde pull-aanvragen. Een pull-aanvraag kan worden ingesteld op automatisch aanvullen met het vereiste aantal goedkeuringen, zelfs als andere revisoren de wijzigingen afwijzen. Vereiste revisoren moeten echter pull-aanvragen goedkeuren voordat de PULL's kunnen worden samengevoegd. Het is een aanbevolen procedure voor ten minste twee revisoren om wijzigingen in een aanzienlijke pull-aanvraag te controleren en goed te keuren.
Als u stemmen opnieuw wilt instellen wanneer een auteur van een pull-aanvraag nieuwe wijzigingen pusht, selecteert u Revisorstemmen opnieuw instellen wanneer er nieuwe wijzigingen zijn in het minimaal aantal revisoren vertakkingsbeleid vereisen.
De volgende tabel bevat een overzicht van de beleidsregels die u kunt definiëren om een vertakking aan te passen. Zie Instellingen en beleidsregels voor Git-opslagplaatsen voor een overzicht van alle beleidsregels en instellingen voor opslagplaatsen en vertakkingen.
Beleid
Standaard
Beschrijving
Uit
Goedkeuring vereisen van een opgegeven aantal revisoren voor pull-aanvragen.
Uit
Traceerbaarheid stimuleren door te controleren op gekoppelde werkitems voor pull-aanvragen
Uit
Controleer of alle opmerkingen zijn opgelost voor pull-aanvragen.
Uit
Besturingselementvertakkingsgeschiedenis door de beschikbare typen samenvoeging te beperken wanneer pull-aanvragen zijn voltooid.
Uit
Voeg een of meer beleidsregels toe om code te valideren door wijzigingen in pull-aanvragen vooraf samen te voegen en samen te voegen. Kan ook beleidsregels in- of uitschakelen.
Uit
Voeg een of meer beleidsregels toe om andere services te verplichten om de status geslaagd te posten om pull-aanvragen te voltooien. Kan ook beleidsregels in- of uitschakelen.
Uit
Voeg een of meer beleidsregels toe om coderevisoren aan te wijzen die automatisch moeten worden opgenomen wanneer pull-aanvragen bepaalde codegebieden wijzigen. Kan ook beleidsregels in- of uitschakelen.
Zie voor meer informatie:
- Overzicht van vertakkingsbeleid
- Vertakkingsbeleid configureren
- Vertakkingsmachtigingen
- Azure Functions gebruiken om aangepast vertakkingsbeleid te maken
Statuscontroles definiëren om de codekwaliteit te verbeteren
Met pull-aanvragen en vertakkingsbeleid kunnen teams best practices afdwingen voor het controleren van code en het uitvoeren van geautomatiseerde builds. Veel teams hebben nog meer vereisten en validaties voor code. U kunt pr-statuscontroles integreren in de pull-werkstroom om aan deze behoeften te voldoen. Met pr-statuscontroles kunnen externe services programmatisch worden afgemeld bij codewijzigingen door succes- of foutinformatie te koppelen aan de pull-aanvraag.
Raadpleeg voor meer informatie de volgende artikelen:
- Werkstromen voor pull-aanvragen aanpassen en uitbreiden met de status van de pull-aanvraag
- Een PR-statusserver maken met Node.js
- Een vertakkingsbeleid configureren voor een externe service
Probleem met meerdere samenvoegingsbasis
In sommige gevallen heeft een pull-aanvraag meer dan één echte samenvoegbasis en kan deze situatie beveiligingsproblemen veroorzaken. Als de bestanden in de pull-aanvraag verschillende versies hebben tussen de samenvoegingsbasissen, treedt er een waarschuwing voor meerdere samenvoegingsbasissen op. Zie Meerdere samenvoegingsbasissen voor meer informatie en herstel.
Volgende stappen
- Codekwaliteit verbeteren met vertakkingsbeleid
- Werkstromen voor pull-aanvragen aanpassen en uitbreiden met de status van de pull-aanvraag
- Meldingen over pull-aanvraagupdates
- De standaardbranch wijzigen
- Wijzigingen kopiëren met cherry-pick
- Strategieën samenvoegen en squash samenvoegen
- Meerdere samenvoegingsbasissen