Come inviare pull request

Per apportare modifiche al contenuto, inviare una pull request dal tuo fork. Una pull request deve essere esaminata prima di poter essere unita. Per ottenere risultati ottimali, esaminare l'elenco di controllo editoriale prima di inviare la richiesta pull.

Uso di rami Git

Il ramo predefinito per PowerShell-Docs è il main ramo . Le modifiche apportate nei rami di lavoro vengono unite nel ramo main prima di essere pubblicate. Il main ramo viene unito nel live ramo ogni giorno feriale alle 17:00 (ora pacifico). Il live ramo contiene il contenuto pubblicato in learn.microsoft.com.

Prima di avviare le modifiche, creare un ramo di lavoro nella copia locale del repository PowerShell-Docs. Quando si lavora in locale, assicurarsi di sincronizzare il repository locale prima di creare il ramo di lavoro. Il ramo di lavoro deve essere creato da una copia datata up-todel ramo main.

Tutti i pull request devono essere indirizzati al branch main. Non inviare modifiche al live ramo. Le modifiche apportate nel main ramo vengono unite in live, sovrascrivendo le modifiche apportate a live.

Far funzionare meglio il processo di pull request per tutti

Più semplice e mirata puoi rendere la tua richiesta pull, più velocemente potrà essere esaminata e unita.

Evitare richieste pull che aggiornano un numero elevato di file o contengono modifiche non correlate

Evitare di creare richieste pull contenenti modifiche non correlate. Separare gli aggiornamenti secondari agli articoli esistenti da nuovi articoli o riscrizioni principali. Lavorare su queste modifiche in rami di lavoro separati.

Le modifiche in blocco creano pull request con un numero elevato di file modificati. Limita i PR a un massimo di 50 file modificati. Le richieste pull di grandi dimensioni sono difficili da esaminare e sono più soggette a contenere errori.

Ridenominazione o eliminazione di file

Quando si rinominano o eliminano file, deve esserci una questione associata alla pull request. Questo problema deve illustrare la necessità di rinominare o eliminare i file.

Evitare di combinare aggiunte o modifiche al contenuto con le ridenominazione e le eliminazioni dei file. Qualsiasi file rinominato o eliminato deve essere aggiunto al file di reindirizzamento appropriato. Quando possibile, aggiornare tutti i file che si collegano al contenuto rinominato o eliminato, inclusi i file TOC.

Evitare di modificare i file di configurazione del repository

Evitare di modificare i file di configurazione del repository. Limitare le modifiche, se possibile, ai file di contenuto Markdown e ai file di immagine di supporto necessari per il contenuto.

Modifiche non corrette ai file di configurazione del repository possono interrompere la compilazione, introdurre vulnerabilità o problemi di accessibilità o violare gli standard dell'organizzazione. I file di configurazione del repository sono tutti i file che corrispondono a uno o più di questi modelli:

• *.yml
• .github/**
• .localization-config
• .openpublishing*
• LICENSE*
• reference/docfx.json
• reference/mapping/**
• tests/**
• ThirdPartyNotices
• tools/**

Per motivi di incolumità e sicurezza, non modificare questi file. Se si ritiene che uno di questi file debba essere modificato, inviare un problema. Dopo che i gestori valutano il problema, apportano le modifiche appropriate.

Usare il modello di richiesta pull

Quando si crea una richiesta pull, un modello viene inserito automaticamente nel corpo della richiesta pull. L'aspetto è simile al seguente:

# PR Summary

<!--
    Delete this comment block and summarize your changes and list
    related issues here. For example:

    This changes fixes problem X in the documentation for Y.

    - Fixes #1234
    - Resolves #1235
-->

## PR Checklist

<!--
    These items are mandatory. For your PR to be reviewed and merged,
    ensure you have followed these steps. As you complete the steps,
    check each box by replacing the space between the brackets with an
    x or by clicking on the box in the UI after your PR is submitted.
-->

- [ ] **Descriptive Title:** This PR's title is a synopsis of the changes it proposes.
- [ ] **Summary:** This PR's summary describes the scope and intent of the change.
- [ ] **Contributor's Guide:** I have read the [contributors guide][contrib].
- [ ] **Style:** This PR adheres to the [style guide][style].

<!--
    If your PR is a work in progress, please mark it as a draft or
    prefix it with "(WIP)" or "WIP:"

    This helps us understand whether or not your PR is ready to review.
-->

[contrib]: /powershell/scripting/community/contributing/overview
[style]: /powershell/scripting/community/contributing/powershell-style-guide

Nella sezione "PR Summary", scrivi un breve riepilogo delle modifiche ed elenca eventuali problemi correlati in base al numero di problema, come #1234. Se la richiesta pull risolve o gestisce il problema, usa la funzionalità di chiusura automatica di GitHub in modo che il problema venga chiuso automaticamente quando viene unita la richiesta pull.

Esaminare gli elementi nella sezione "Elenco di controllo delle richieste pull" e controllarli man mano che ne hai completato ognuno. È necessario seguire le istruzioni e controllare ogni elemento affinché il team approvi la pull request.

Se la tua richiesta pull è in corso, impostala sulla modalità bozza o anteponi al titolo della tua richiesta pull il prefisso WIP.

Commento aspettative

Dopo aver inviato la pull request, un bot commenterà su di essa. Il commento fornisce risorse e imposta le aspettative per il resto del processo. È possibile aggiornare periodicamente questo commento, quindi rivedere sempre il commento, anche se questo non è il primo contributo.

Servizio di convalida delle richieste pull della documentazione

Il servizio di convalida Docs PR è un'app GitHub che applica le regole di convalida alle tue modifiche. È necessario correggere eventuali errori o avvisi segnalati dal servizio di convalida.

I passaggi seguenti descrivono il comportamento di convalida:

1. Si invia una richiesta pull.

2. Nel commento di GitHub che indica lo stato dei "controlli" abilitati nel repository. In questo esempio sono disponibili due controlli abilitati, "Convalida commit" e "OpenPublishing.Build":

   

   La compilazione può andare a buon fine anche se la convalida del commit fallisce.

3. Selezionare Dettagli per altre informazioni. La pagina Dettagli mostra tutti i controlli di convalida non riusciti e include informazioni su come risolvere i problemi.

4. Quando la convalida ha esito positivo, il commento seguente viene aggiunto alla richiesta pull:

   

Annotazioni

Se si è un collaboratore esterno (non un dipendente Microsoft), non si ha accesso ai report di compilazione dettagliati o ai collegamenti di anteprima.

Quando viene esaminata la richiesta pull, potrebbe esserti chiesto di apportare modifiche o correggere i messaggi di avviso di convalida. Il team PowerShell-Docs può aiutare a comprendere gli errori di convalida e i requisiti editoriali.

Azioni di GitHub

Diverse azioni GitHub Actions vengono eseguite contro le tue modifiche per convalidare e fornire contesto a te e ai revisori.

Verifica dell'elenco di controllo

Se la richiesta pull non è in modalità bozza e non è preceduta da WIP, un'azione GitHub controlla la richiesta pull per verificare che sia stato selezionato ogni elemento nell'elenco di controllo del modello di richiesta pull. I responsabili non esamineranno o uniranno la PR finché non completi l'elenco di controllo. Gli elementi dell'elenco di controllo sono obbligatori.

Verifica dell'autorizzazione

Se la richiesta pull è destinata al live ramo o modifica i file di configurazione del repository, un'azione GitHub controlla le autorizzazioni per verificare che l'utente sia autorizzato a inviare tali modifiche.

Solo gli amministratori del repository sono autorizzati a specificare come destinazione il ramo o modificare i file di configurazione del live repository.

Report delle modifiche ai contenuti versionati

Se la tua richiesta pull aggiunge, rimuove o modifica contenuti con controllo delle versioni, un'azione GitHub analizza le modifiche e scrive un rapporto che riepiloga i tipi di modifiche apportate ai contenuti con controllo delle versioni.

Questo report può indicare se sono presenti altre versioni dei file che è necessario aggiornare in questa pull request.

Per trovare il report sul contenuto versionato per la pull request:

1. Seleziona la scheda "Controlli" nella pagina della pull request.
2. Seleziona il lavoro "Reporting" dall'elenco dei lavori.
3. Selezionare il pulsante "..." in alto a destra.
4. Selezionare "Visualizza riepilogo lavoro".

Passaggi successivi

guida di stilePowerShell-Docs

Risorse aggiuntive

Come vengono gestite le richieste pull