Condividi tramite

Gestione delle richieste pull

Questo articolo illustra come gestire le richieste pull nel repository PowerShell-Docs. Questo articolo è progettato per essere un aiuto di lavoro per i membri del team PowerShell-Docs. Queste informazioni vengono pubblicate qui per garantire la trasparenza dei processi per i collaboratori pubblici.

Procedure consigliate

  • Richiedere una revisione. La persona che invia il PR non deve unire il PR senza una review tra pari.
  • Assegnare il revisore paritario in occasione dell'invio della richiesta pull. L'assegnazione anticipata consente al revisore di rispondere prima con le osservazioni editoriali.
  • Usare i commenti per descrivere la natura della modifica inviata. Ad esempio, se la modifica è secondaria, spiegare la modifica e che non è necessaria una revisione tecnica completa. Assicurati di @mention il revisore.
  • Usare la funzionalità di suggerimento di commento per semplificare l'accettazione della modifica suggerita da parte dell'autore. Per altre informazioni, vedere Revisione delle modifiche proposte in una richiesta pull.

Passaggi del processo di Pull Request

  1. Writer: Creare una richiesta pull
    • Compilare il modello di richiesta pull
    • Collega eventuali problemi risolti dal PR
    • Usare la funzionalità di chiusura automatica di GitHub per chiudere il problema
    • Eseguire e controllare ogni elemento nell'elenco di controllo
  2. Writer: Assegnare revisore tra pari
  3. Revisore: correzioni e commenti (se necessario)
  4. Integrare il feedback della revisione
  5. Entrambi: esaminare il rendering dell'anteprima
  6. Entrambi: esaminare il report di convalida - correggere gli avvisi e gli errori
  7. Revisore: contrassegnare la revisione "Approvato"
  8. Responsabile del repository: Unisci PR

Elenco di controllo per i revisori del contenuto

Vedi l'elenco di controllo editoriale per un elenco più completo.

  • Correzione per grammatica, stile, concisione, accuratezza tecnica
  • Verificare che gli esempi siano ancora validi per la versione di destinazione
  • Controllare il rendering dell'anteprima
  • Controllare i metadati - ms.date, rimuovere ms.assetid, verificare i campi obbligatori
  • Verificare la correttezza del markdown
    • Vedere la guida di stile per le regole di formattazione specifiche del contenuto
  • Riorganizzare gli esempi come segue:
    • Paragrafo introduttivo
    • Codice e output
    • Spiegazione dettagliata del codice (se necessario)
  • Controllare l'accuratezza dei collegamenti ipertestuali
    • Sostituire o rimuovere collegamenti TechNet/MSDN
    • Verificare il numero minimo di reindirizzamenti alla destinazione
    • Assicurarsi che venga utilizzato HTTPS
    • Tipo di collegamento corretto
      • Collegamenti di file per i file locali
      • Collegamenti URL per i file all'esterno del docset
    • Rimuovere le impostazioni locali dagli URL
    • Semplificare gli URL che puntano a learn.microsoft.com
  • Verificare che il contenuto versionato sia corretto in tutte le versioni

Processo di merge dei rami

Il main ramo è l'unico ramo che deve essere unito a live. I merge da rami di lavoro di breve durata devono essere squashati prima dell'unione in main.

Unisci da/a ramo di rilascio principale in diretta
ramo di lavoro comprimere e unire (squash e merge) comprimere e unire (squash e merge) Non consentito
ramo di rilascio — unisci Non consentito
principale riallineamento — unisci

Elenco di controllo per la fusione delle Pull Request

  • Revisione del contenuto completata
  • Correggere il ramo di destinazione per la modifica
  • Nessun conflitto di merge
  • Tutti i passaggi di convalida e di compilazione sono stati superati
    • Gli avvisi e i suggerimenti devono essere corretti (vedere Note per le eccezioni)
    • Nessun collegamento interrotto
    • L'azione elenco di controllo è stata eseguita e passata
    • Se è stato attivato un controllo di autorizzazione , è stato passato
  • Unire in base alla tabella

Note

È possibile ignorare gli avvisi seguenti:

Can't find service name for `<version>/<modulepath>/About/About.md`

Metadata with following name(s) are not allowed to be set in YAML header, or as file level
metadata in docfx.json, or as global metadata in docfx.json: `locale`. They are generated by
Docs platform, so the values set in these 3 places will be ignored. Please remove them from all
3 places to resolve the warning.

Quando viene unita una pull request, il HEAD del ramo di destinazione viene modificato. Tutte le pull request aperte sulla base dell'HEAD precedente sono ora obsolete. Un manutenitore ha il diritto necessario per eseguire l'override degli avvisi di merge e unire la richiesta pull obsoleta in GitHub. La fusione di una PR superata è sicura se le PR precedenti non hanno toccato gli stessi file.

Per aggiornare la pull request, seleziona il pulsante Aggiorna branch. Scegliere l'opzione Aggiorna con rebase. Per ulteriori informazioni, vedere Aggiornamento del branch di pull request.

Pubblicazione su Live

Periodicamente, le modifiche accumulate nel main ramo devono essere pubblicate nel sito Web live.

  • Il main ramo viene unito a live ogni giorno feriale alle 19:00 PST.
  • Il main ramo deve essere unito a live dopo qualsiasi modifica significativa.
    • Modifiche a 50 o più file
    • Dopo la fusione di un ramo di rilascio
    • Modifiche alle configurazioni del repository o del docset (docfx.json, configurazioni OPS, script di compilazione e così via)
    • Modifiche al file di reindirizzamento
    • Modifiche apportate al sommario
    • Dopo aver unito un ramo "progetto" (riorganizzazione del contenuto, aggiornamento in blocco e così via)
  • Last updated on