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 PR gemaakt, maar deze is nog niet ingediend in de inzendingswachtrij 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

Schermopname van een geopende pull-aanvraag.

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

  • 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 Commits: een overzicht van de wijzigingen die zijn aangebracht in die tak.
  • Tabblad Bestanden gewijzigd: een vergelijking van de gewijzigde bestanden in de pull request met hun 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 hashtag-opmerkingen toevoegen om acties uit te voeren, zoals het goedkeuren van de pull-aanvraag om aan te geven dat deze gereed is om te worden gevalideerd en samengevoegd, of uitstellen 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 request kan worden samengevoegd in de doelbranche, kan het nodig zijn om één of meer PR-validatieprocessen door te geven. Nadat u Pull-aanvraag maken hebt geselecteerd, voert GitHub de validaties uit die zijn geconfigureerd voor uw opslagplaats. Wanneer het validatieproces is voltooid, worden de resultaten weergegeven in de pull request.

Validatieprocessen variëren afhankelijk van het bereik van voorgestelde wijzigingen en de regels van de doelopslagplaats. Nadat u uw pull request hebt ingediend, kunt u een of meer van de volgende gebeurtenissen 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 request aangeeft dat deze test is mislukt, moet u de inhoud oplossen die het samenvoegingsconflict veroorzaakt voordat de verwerking verder kan gaan.
  • Bijdragelicentieovereenkomst (CLA): Als je bijdraagt aan een openbare opslagplaats en geen werknemer van Microsoft bent, kan je gevraagd worden om een korte CLA in te vullen, afhankelijk van de omvang van de voorgestelde wijzigingen, de eerste keer dat je een pull-verzoek indient bij die opslagplaats. Nadat de CLA-stap is afgerond, wordt uw pull-verzoek verwerkt.
  • Labelen: Labels worden automatisch toegepast op uw pull request om de status ervan aan te geven wanneer deze de validatiewerkstroom doorloopt. Nieuwe pull-aanvragen kunnen bijvoorbeeld automatisch het do-not-merge label 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 request voordat deze kan worden gemerged. De resultaten van de validatietest worden als opmerking toegevoegd in uw pull request ter beoordeling, en ze kunnen ook via e-mail naar u worden 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 PR-opmerking weergegeven.
  • Automatisch samenvoegen: de pull-aanvraag kan automatisch worden samengevoegd als deze voldoet aan validatietesten en specifieke criteria. In dit geval hoeft u niets anders te doen.

Controleren en goedkeuren

U bent bijna klaar. Nadat alle PR-verwerking is voltooid, is het beste praktijk om de resultaten (bijvoorbeeld PR-opmerkingen, preview-URL's) te bekijken om te bepalen of er meer wijzigingen nodig zijn voordat u goedkeurt voor samenvoeging. 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 commentaarautomatisering om belangrijke acties uit te voeren in de pull request. Met automatisering van opmerkingen kunnen gebruikers het juiste label toewijzen aan hun pull request om de status bij te werken of het te categoriseren. Als u in een repository werkt waarin automatisering van opmerkingen is geïmplementeerd, gebruikt u de hashtag-opmerkingen om labels toe te wijzen of te wijzigen, een pull request te sluiten of het samenvoegen te onderbreken. Wanneer u bijvoorbeeld klaar bent met het aanbrengen van wijzigingen, typt u de opmerking #sign-off van waaruit u het pr-label wilt wijzigen in do-not-mergeready-for-review.

Gebruik de opmerkingen in de volgende tabel om belangrijke acties uit te voeren in uw pull request.

Hashtag-opmerking Wat het doet
#sign-off Wijst automatisch het ready-to-merge label toe om de reviewers in de repository te laten weten dat de pull-aanvraag klaar is voor beoordeling en samenvoegen.

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

U moet de #sign-off opmerking invoeren om uw wijzigingen samen te voegen. Zelfs als alle beoordelingen en validatiecontroles zijn geslaagd, bent u verantwoordelijk voor het gebruik van dit commentaar om de pull-aanvraagbeoordelaars en repositorybeheerders te laten weten dat uw wijzigingen gereed zijn voor samenvoeging vanuit uw kant. Wanneer de beoordelaars bepalen dat uw pull-aanvraag probleemvrij is en goedgekeurd, worden uw wijzigingen weer samengevoegd in de hoofdvertakking en wordt de pull-aanvraag gesloten.

Schermopname van het opmerkingenvak op een pull request met #sign-off getypt in het opmerkingenveld en de knop Opmerking is gemarkeerd.

Publiceren

Vergeet niet dat uw PR moet worden samengevoegd door een PR-reviewer voordat de wijzigingen kunnen worden opgenomen in de volgende geplande publicatieronde. Normaal gesproken worden PR's beoordeeld en gemerged 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 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

Op basis van uw eerdere ervaring zag u een kans om nuttige informatie toe te voegen aan een App Service-documentatiepagina en maakte u een pull request om uw wijzigingen toe te voegen. U bent nu klaar om uw PR te beoordelen en goed te keuren zodat uw wijzigingen gepubliceerd kunnen worden.