Condividi tramite


Elaborare una richiesta pull

Dopo aver aperto una richiesta pull, la richiesta pull viene sottoposta a un set di controlli e revisioni per assicurarsi che le modifiche proposte possano essere unite. Per altre informazioni sulle richieste pull, vedere Nozioni fondamentali su Git e GitHub.

Convalida

Prima che la richiesta pull possa essere unita al ramo di destinazione, potrebbe essere necessario passare uno o più processi di convalida della richiesta pull. Dopo aver selezionato Crea richiesta pull, GitHub esegue le convalide configurate per il repository. Al termine del processo di convalida, i risultati vengono visualizzati nella richiesta pull.

I processi di convalida variano a seconda dell'ambito delle modifiche proposte e delle regole del repository di destinazione. Dopo aver inviato la richiesta pull, è possibile prevedere che si verifichino una o più delle operazioni seguenti:

  • Unionebilità: si verifica prima un test di mergebilità di GitHub di base per verificare se le modifiche proposte nel ramo sono in conflitto con il ramo di destinazione. Se la richiesta pull indica che questo test non è riuscito, è necessario riconciliare il contenuto che causa il conflitto di merge prima che l'elaborazione possa continuare.
  • Contratto di licenza per i contributi (CLA): in qualità di collaboratore non Microsoft, se si contribuisce a un repository pubblico, potrebbe essere richiesto di completare un breve contratto di licenza per la prima volta che si invia una richiesta pull a tale repository. Dopo aver cancellato il passaggio CLA, la richiesta pull viene elaborata.
  • Etichettatura: le etichette vengono applicate automaticamente alla richiesta pull per indicare lo stato della richiesta mentre attraversa il flusso di lavoro di convalida. Ad esempio, le nuove richieste pull potrebbero ricevere automaticamente l'etichetta "non unire", a indicare che la richiesta pull non ha ancora completato la convalida, la revisione e i passaggi di approvazione.
  • Convalida e compilazione: una serie di controlli automatici verificano se le modifiche superano i test di convalida. I test di convalida potrebbero generare avvisi o errori, richiedendo di modificare uno o più file nella richiesta pull prima di poter essere uniti. I risultati del test di convalida vengono aggiunti come commento nella richiesta pull per la revisione e potrebbero essere inviati all'utente tramite posta elettronica.
  • Gestione temporanea: al termine della convalida e della compilazione, gli articoli modificati vengono distribuiti automaticamente in un ambiente di gestione temporanea per la revisione. Gli URL di anteprima appaiono in un commento della richiesta pull.
  • Unione automatica: la richiesta pull potrebbe essere unita automaticamente, se supera i test di convalida e determinati criteri. In questo caso, non è necessario eseguire altre operazioni.

Esaminare e risolvere i commenti e i suggerimenti

Al termine dell'elaborazione delle richieste pull, è consigliabile esaminare i risultati, ad esempio i commenti della richiesta pull e i risultati della compilazione. Determinare se è necessario apportare altre modifiche prima di disconnettersi per l'unione. Potrebbe essere necessario modificare il contenuto per uno dei motivi seguenti:

  • Commenti delle richieste pull dai revisori. Se un revisore della richiesta pull ha esaminato la richiesta pull, può fornire commenti tramite commenti in caso di problemi o domande da risolvere prima dell'unione.
  • Feedback dei revisori peer.
  • Correzioni di formattazione dovute a problemi di rendering.
  • Errori o avvisi di convalida.
  • Conflitti di merge.

Se è necessario apportare modifiche, è possibile modificare il contenuto direttamente nella richiesta pull oppure tornare a VS Code per apportare le modifiche. Al termine, eseguire il commit delle modifiche nel ramo di lavoro. La richiesta pull viene aggiornata automaticamente con le modifiche apportate.

Ogni volta che si aggiunge un commit allo stesso ramo di lavoro, il commit viene aggiunto automaticamente alla richiesta pull. Con ogni commit, il sistema di pubblicazione esegue nuovamente i processi di convalida e revisione automaticamente.

Disconnettersi e aggiungere commenti all'automazione

Dopo aver risolto tutti gli errori di feedback e convalida e si è pronti per il merge delle modifiche, è possibile disconnettersi dalla richiesta pull creando un nuovo commento che legge #sign-off. È necessario immettere il #sign-off commento per unire le modifiche. Anche se vengono superate tutte le verifiche e i controlli di convalida, si è responsabili dell'uso di questo commento per indicare ai revisori delle richieste pull e agli amministratori del repository che le modifiche sono pronte per l'unione.

Quando i revisori determinano che la richiesta pull è senza problemi e non è stata eseguita la disconnessione, le modifiche vengono unite nel ramo predefinito e la richiesta pull viene chiusa.

L'automazione dei commenti consente agli utenti che non hanno autorizzazioni di scrittura in un repository per completare un'azione a livello di scrittura assegnando l'etichetta appropriata a una richiesta pull. Se si lavora in un repository in cui è stata implementata l'automazione dei commenti, usare i commenti hashtag elencati nella tabella seguente per assegnare etichette, modificare le etichette o chiudere una richiesta pull. Gli autori Microsoft riceveranno inoltre una notifica tramite posta elettronica per la revisione e la disconnettersi ogni volta che vengono proposte modifiche ai propri articoli.

Commento hashtag Risultato
#sign-off Assegna automaticamente l'etichetta pronta per l'unione per informare i revisori nel repository che la richiesta pull è pronta per la revisione/unione.

Se non si è l'autore elencato e si tenta di disconnettersi da una richiesta pull pubblica usando il #sign-off commento, la richiesta pull viene aggiornata per indicare che solo l'autore può assegnare l'etichetta.
#hold-off Rimuove l'etichetta pronta per l'unione, nel caso in cui si cambi idea o si commetta un errore. Nel repository privato viene assegnata l'etichetta do-not-merge.
#please-close Chiude la richiesta pull se si decide di non unire le modifiche.
#please-open Riapre una richiesta pull o un problema chiuso.

Pubblicazione

La richiesta pull deve essere unita da un revisore della richiesta pull prima che le modifiche possano essere incluse nella successiva esecuzione della pubblicazione pianificata. In genere, le richieste pull vengono esaminate e unite nell'ordine di invio.

Dopo l'approvazione e l'unione dei contributi, il processo di pubblicazione ne effettua il prelievo. A seconda del team che gestisce il repository a cui si contribuisce, i tempi di pubblicazione possono variare, ma in genere si verificano almeno una volta ogni giorno feriale. Per la visualizzazione online degli articoli dopo la pubblicazione possono essere richiesti fino a 45 minuti.

Una volta pubblicate le modifiche, saranno live su Microsoft Learn per consentire ad altri utenti di trarne insegnamento.

Passaggi successivi

Ecco fatto! È stato fornito un contributo al contenuto di Microsoft Learn.