Een pull-aanvraag controleren en verzenden

Voltooid

De pull-aanvraag (PR) is uw ticket om uw kennis op het Learn-platform te krijgen. U hebt een pull-aanvraag gemaakt, maar deze is nog niet verzonden naar de pull-aanvraagwachtrij van de doelopslagplaats. Net als bij veel opensource-projecten zijn er een reeks controles en beoordelingen die plaatsvinden om wijzigingen te valideren voordat ze worden gepubliceerd.

Anatomie van een pull-aanvraag

Screenshot of an open pull request.

Een pull-aanvraag toont de GitHub-gebruiker die de pull-aanvraag heeft gemaakt, de doelopslagplaats en de vertakking waarin de pull-aanvraag is gemaakt. PULL's bevatten bovenaan verschillende tabbladen, waaronder:

  • Gesprekstabblad : een dashboard waar u opmerkingen van andere medewerkers kunt bekijken en beantwoorden, een lijst met meldingen kunt bekijken tijdens het bouw- en controleproces en opmerkingenautomatisering kunt gebruiken om acties uit te voeren.
  • Tabblad Doorvoeringen : een record van de wijzigingen die zijn aangebracht in die vertakking.
  • Tabblad Bestanden gewijzigd : een vergelijking van de gewijzigde bestanden in de pull-aanvraag met de eerdere status.

Let op het tabblad Gesprek, waar updates of meldingen worden weergegeven en eventuele discussies tussen u, de revisoren en andere medewerkers plaatsvinden. U kunt hier ook hashtagopmerkingen toevoegen om acties uit te voeren, zoals het afmelden bij de pull-aanvraag om aan te geven dat deze gereed is om te worden gevalideerd en samengevoegd, of als u het proces wilt onderbreken.

Pull-aanvragen hebben vaak labels gekoppeld om hun status aan te geven, zoals draft het opgeven van concept-PULL's die niet gereed zijn voor beoordeling of do-not-merge voor PULL's die nieuw of niet worden bekeken.

Validatie

Voordat uw pull-aanvraag kan worden samengevoegd in de doelbranch, kan het nodig zijn om een of meer pr-validatieprocessen door te geven. Nadat u Pull-aanvraag maken hebt geselecteerd, worden in GitHub de validaties uitgevoerd die zijn geconfigureerd voor uw opslagplaats. Wanneer het validatieproces is voltooid, worden de resultaten weergegeven in de pull-aanvraag.

Validatieprocessen variëren afhankelijk van het bereik van voorgestelde wijzigingen en de regels van de doelopslagplaats. Nadat u uw pull-aanvraag hebt ingediend, kunt u een of meer van de volgende dingen verwachten:

  • Samenvoegbaarheid: Er wordt eerst een GitHub-samenvoegbaarheidstest uitgevoerd om te controleren of de voorgestelde wijzigingen in uw vertakking conflicteren met de doelvertakking. Als de pull-aanvraag aangeeft dat deze test is mislukt, moet u de inhoud afstemmen die het samenvoegingsconflict veroorzaakt voordat de verwerking kan worden voortgezet.
  • Bijdragelicentieovereenkomst (CLA): Als u een bijdrage levert aan een openbare opslagplaats en geen Microsoft-werknemer bent, wordt u mogelijk gevraagd om een korte CLA te voltooien wanneer u voor het eerst een pull-aanvraag indient bij die opslagplaats. Nadat de CLA-stap is gewist, wordt uw pull-aanvraag verwerkt.
  • Labelen: labels worden automatisch toegepast op uw pull-aanvraag om de status van uw pull-aanvraag aan te geven terwijl deze de validatiewerkstroom doorloopt. Nieuwe pull-aanvragen kunnen bijvoorbeeld automatisch het label 'do not-merge' ontvangen, waarmee wordt aangegeven dat de pull-aanvraag de stappen voor validatie, controle en afmelding nog niet heeft voltooid.
  • Validatie en build: Uw wijzigingen worden door geautomatiseerde controles onderzocht om te controleren of ze de validatietests doorstaan. De validatietests kunnen waarschuwingen of fouten opleveren, waardoor u wijzigingen moet aanbrengen in een of meer bestanden in uw pull-aanvraag voordat deze kan worden samengevoegd. De resultaten van de validatietest worden toegevoegd als opmerking in uw pull-aanvraag voor uw beoordeling en ze worden mogelijk ook per e-mail naar u verzonden.
  • Fasering: De artikelpagina’s die worden beïnvloed door uw wijzigingen, kunnen automatisch in een faseringsomgeving worden geïmplementeerd voor controle na een succesvolle validatie en build. Voorbeeld-URL’s worden in een pull-aanvraagopmerking weergegeven.
  • Automatisch samenvoegen: de pull-aanvraag kan automatisch worden samengevoegd als deze voldoet aan validatietests en bepaalde criteria. In dit geval hoeft u niets anders te doen.

Controleren en afmelden

Je bent er bijna! Nadat alle pull-aanvragen zijn voltooid, is het raadzaam om de resultaten (bijvoorbeeld PR-opmerkingen, preview-URL's) te bekijken om te bepalen of er meer wijzigingen nodig zijn voordat u zich afmeldt voor samenvoegen. Als een revisor voor pull-aanvragen uw pull-aanvraag heeft beoordeeld, kan deze ook feedback geven via opmerkingen als er openstaande problemen of vragen zijn die de samenvoeging verhinderen.

Gebruik automatisering van opmerkingen om belangrijke acties uit te voeren in de pull-aanvraag. Met automatisering van opmerkingen kunnen gebruikers het juiste label toewijzen aan hun pull-aanvraag om de status bij te werken of te categoriseren. Als u in een opslagplaats werkt waarin automatisering van opmerkingen is geïmplementeerd, gebruikt u de hashtagopmerkingen om labels toe te wijzen of te wijzigen, een pull-aanvraag te sluiten of het samenvoegen te onderbreken. Wanneer u bijvoorbeeld klaar bent met het aanbrengen van wijzigingen, typt u de opmerking '#sign-off' om het pr-label te wijzigen van do-not-merge in ready-for-review.

Gebruik de opmerkingen in de volgende tabel om belangrijke acties uit te voeren in uw pull-aanvraag:

Hashtag-opmerking Wat het doet
#sign-off Wijst automatisch het label gereed voor samenvoeging toe om de revisoren in de opslagplaats te laten weten dat de pull-aanvraag gereed is voor beoordeling/samenvoegen.

Als u niet de vermelde auteur bent en probeert u zich af te melden bij een openbare opslagplaats met behulp van de #sign-off opmerking, wordt de pull-aanvraag bijgewerkt om aan te geven dat alleen de auteur het label kan toewijzen.
#hold-off Hiermee verwijdert u het kant-en-klare label voor het geval u van gedachten verandert of een fout maakt.
#please-close Hiermee sluit u de pull-aanvraag als u besluit de wijzigingen niet samen te voegen.
#please-open Opent een gesloten pull-aanvraag of een gesloten probleem opnieuw.

U moet de opmerking invoeren #sign om uw wijzigingen samen te voegen. Zelfs als alle beoordelingen en validatiecontroles zijn geslaagd, bent u verantwoordelijk voor het gebruik van deze opmerking om de revisoren van pull-aanvragen en opslagplaatsbeheerders te laten weten dat uw wijzigingen gereed zijn voor samenvoeging vanuit uw kant van zaken. Wanneer de revisoren bepalen dat uw pull-aanvraag probleemloos is en is afgemeld, worden uw wijzigingen weer samengevoegd in de bovenliggende vertakking en wordt de pull-aanvraag gesloten.

Screenshot of the comment box on a PR with #sign-off typed into the comment field and the Comment button highlighted.

Publiceren

Vergeet niet dat uw pull-aanvraag moet worden samengevoegd door een revisor voor pull-aanvragen voordat de wijzigingen kunnen worden opgenomen in de volgende geplande publicatieuitvoering. Normaal gesproken worden pull-aanvragen beoordeeld en samengevoegd in volgorde van indiening.

Nadat uw bijdragen zijn goedgekeurd en samengevoegd, worden deze door het publicatieproces opgehaald. Afhankelijk van het team dat de opslagplaats beheert waaraan u een bijdrage levert, kunnen de publicatietijden variëren, maar meestal ten minste één keer per weekdag. Het kan tot 45 minuten duren voordat artikelen online verschijnen nadat ze zijn gepubliceerd.

Zodra uw wijzigingen zijn gepubliceerd, gaan ze live naar Microsoft Learn, zodat anderen kunnen beginnen met leren.

Scenario: Wijzigingen publiceren in Azure-app Service

Met uw ervaring in het verleden hebt u een kans gezien om nuttige informatie toe te voegen aan een App Service-documentatiepagina en een pull-aanvraag gemaakt om uw wijzigingen toe te voegen. U bent nu klaar om uw pull-aanvraag te bekijken en af te melden om uw bewerkingen te publiceren.