Se gjennom og send inn en pull-forespørsel
Pull-forespørselen (PR) er din billett til å få kunnskapen din på Learn-plattformen. Du har opprettet en pr, men den er ennå ikke sendt til målrepositoriets PR-kø. Som med mange prosjekter med åpen kildekode, finnes det en rekke kontroller og anmeldelser som finner sted for å validere endringer før publisering.
Anatomi av en PR
En pr viser GitHub-brukeren som opprettet pr, målrepositoriet og grenen der pr ble opprettet. PR-er inneholder flere faner øverst, inkludert:
- Samtale-fanen: Et instrumentbord der du kan vise og svare på kommentarer fra andre samarbeidspartnere, se en liste over varsler gjennom hele prosessen for bygg og gjennomgang, og bruke kommentarautomatisering til å utføre handlinger.
- Utføringer-fanen: En post over endringene som er gjort i denne grenen.
- Filer endret-fanen: En sammenligning av de endrede filene i PR-en med den tidligere tilstanden.
Vær oppmerksom på samtalefanen, der eventuelle oppdateringer eller varsler vises, og eventuelle diskusjoner mellom deg, korrekturleserne og andre samarbeidspartnere finner sted. Du kan også legge til emneknaggkommentarer her for å utføre handlinger, for eksempel logge av på pr for å indikere at den er klar til å valideres og slås sammen, eller holde av hvis du trenger å stanse prosessen midlertidig.
PR-er har ofte etiketter knyttet til for å angi status, for eksempel draft for å angi kladde-PR-er som ikke er klare for gjennomgang, eller do-not-merge for PR-er som er nye eller uvisse.
Validering
Før pr-forespørselen kan slås sammen til målgrenen, kan det være nødvendig å gå gjennom én eller flere PR-valideringsprosesser. Når du har valgt Opprett pull-forespørsel, kjører GitHub valideringene som er konfigurert for repositoriet. Når valideringsprosessen er ferdig, vises resultatene i pr.
Valideringsprosesser varierer avhengig av omfanget av foreslåtte endringer og reglene for målrepositoriet. Når du har sendt inn en pr, kan du forvente at ett eller flere av følgende skal skje:
- Mergeability: En gitHub-sammenslåingstest for grunnlinje forekommer først for å bekrefte om de foreslåtte endringene i grenen er i konflikt med målgrenen. Hvis pr indikerer at denne testen mislyktes, må du avstemme innholdet som forårsaker sammenslåingskonflikten før behandlingen kan fortsette.
- contribution licensing agreement (CLA): Hvis du bidrar til et offentlig repositorium og ikke er en Microsoft-ansatt, avhengig av størrelsen på de foreslåtte endringene, kan du bli bedt om å fullføre en kort CLA første gang du sender inn en PR til dette repositoriet. Når CLA-trinnet er fjernet, behandles pr-forespørselen din.
-
Merking: Etiketter brukes automatisk på pr for å angi tilstanden når den passerer gjennom valideringsarbeidsflyten. Nye PC-er kan for eksempel automatisk motta
do-not-merge-etiketten, noe som angir at pr ennå ikke har fullført trinnene for validering, gjennomgang og avlogging. - Validering og bygg: Automatiserte kontroller kontrollerer om endringene består valideringstester. Valideringstestene kan gi advarsler eller feil, noe som krever at du gjør endringer i én eller flere filer i pull-forespørselen før den kan slås sammen. Resultatene for valideringstesten legges til som en kommentar i pr for din gjennomgang, og de kan også sendes til deg via e-post.
- Staging: Artikkelsidene som påvirkes av endringene, distribueres automatisk til et oppsamlingsmiljø for gjennomgang ved vellykket validering og bygg. Forhåndsvisning av URL-adresser vises i en PR-kommentar.
- Automatisk fletting: Pr kan automatisk slås sammen hvis den består valideringstesting og bestemte kriterier. I dette tilfellet trenger du ikke å gjøre noe annet.
Se gjennom og logg av
Du er nesten der! Når all PR-behandling er fullført, er det anbefalt fremgangsmåte å se gjennom resultatene (for eksempel PR-kommentarer, forhåndsvise nettadresser) for å avgjøre om flere endringer kreves før du logger av for fletting. Hvis en PR-anmelder har gjennomgått pr-forespørselen din, kan de også gi tilbakemelding via kommentarer hvis det er utestående problemer eller spørsmål som hindrer flettingen.
Bruk kommentarautomatisering til å utføre viktige handlinger i pull-forespørselen. Kommentarautomatisering gjør det mulig for brukere å tilordne riktig etikett til sin pr for å oppdatere tilstanden eller kategorisere den. Hvis du arbeider i et repositorium der kommentarautomatisering er implementert, kan du bruke emneknaggkommentarene til å tilordne eller endre etiketter, lukke en PR eller stanse sammenslåingen midlertidig. Når du for eksempel er ferdig med å gjøre endringer, skriver du inn kommentaren #sign-off for å endre PR-etiketten fra do-not-merge til ready-for-review.
Bruk kommentarene i tabellen nedenfor til å utføre viktige handlinger i pr-forespørselen:
| Hashtag-kommentar | Hva den gjør |
|---|---|
#sign-off |
Tilordner automatisk ready-to-merge-etiketten for å la korrekturleserne i repo vite at PR er klar for gjennomgang/fletting. Hvis du er ikke den oppførte forfatteren og prøver å logge av på en offentlig repo PR ved hjelp av #sign-off kommentar, oppdateres PR for å indikere at bare forfatteren kan tilordne etiketten. |
#hold-off |
Fjerner ready-to-merge etiketten i tilfelle du ombestemmer deg eller gjør en feil. |
#please-close |
Lukker pull-forespørselen hvis du bestemmer deg for ikke å slå sammen endringene. |
#please-open |
Åpner en lukket pr eller et lukket problem på nytt. |
Du må skrive inn #sign-off kommentar for å flette endringene. Selv om alle vurderinger og valideringskontroller passerer, er du ansvarlig for å bruke denne kommentaren til å fortelle PR-anmeldere og repoadministratorer at endringene er klare for sammenslåing fra din side av ting. Når korrekturleserne fastslår at pr er problemfri og logget av, flettes endringene tilbake til den overordnede grenen, og PR-forespørselen lukkes.
Forlagsvirksomhet
Husk at pr-forespørselen må slås sammen av en PR-korrekturleser før endringene kan inkluderes i neste planlagte publiseringskjøring. Vanligvis blir PR-er gjennomgått og slått sammen i rekkefølge av innsending.
Når bidragene dine er godkjent og slått sammen, henter publiseringsprosessen dem opp. Avhengig av teamet som administrerer repositoriet du bidrar til, kan publiseringstiden variere, men de forekommer vanligvis minst én gang hver ukedag. Det kan ta opptil 45 minutter før artikler vises på nettet etter publisering.
Når endringene er publisert, går de direkte på Microsoft Learn for andre å begynne å lære av!
Scenario: Publisere endringer i Azure App Service
Ved hjelp av tidligere erfaringer oppdaget du en mulighet til å legge til nyttig informasjon på en apptjenestedokumentasjonsside og opprettet en PR for å legge til endringene. Du er nå klar til å se gjennom og logge av på PR-en for å publisere endringene.