Informazioni sulle richieste pull
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Le richieste pull sono un modo per modificare, esaminare e unire il codice in un repository Git in Azure Repos. Le richieste pull possono provenire da rami all'interno dello stesso repository o dai rami nel fork del repository. Teams usa le richieste pull per esaminare il codice e fornire commenti e suggerimenti sulle modifiche prima di unire il codice nel ramo principale. I revisori possono eseguire le modifiche proposte, lasciare commenti e votare per approvare o rifiutare il codice.
Questo articolo descrive le linee guida per le richieste pull e le considerazioni sulla gestione. Per istruzioni su come creare, visualizzare, esaminare e completare le richieste pull, vedere gli articoli seguenti:
- Creare richieste pull
- Visualizzare e aprire le richieste pull
- Esaminare le richieste pull
- Completare le richieste pull
Nota
Per motivi di prestazioni e stabilità, il numero di revisori che possono essere aggiunti a una richiesta pull deve essere pari o inferiore a 1000. Le nuove richieste pull non verranno create quando si aggiungono più di 1000 revisori e le richieste pull esistenti non consentono di aggiungere più di 1000 revisori.
Autorizzazioni e prerequisiti
I repository devono essere abilitati nel progetto. Se l'hub Repos e le pagine associate non vengono visualizzate, vedere Attivare o disattivare un servizio Azure DevOps per riabilitare Repos.
Per visualizzare o esaminare le richieste pull, è necessario essere membri di un progetto Azure DevOps con accesso basic o versione successiva.
- Se non si ha un progetto, crearne uno o iscriverti gratuitamente.
- Se non si è membri del progetto, viene aggiunto.
Per contribuire a una richiesta pull, è necessario essere membri del gruppo di sicurezza Lettori o disporre delle autorizzazioni corrispondenti.
Per creare e completare una richiesta pull, è necessario essere membri del gruppo di sicurezza Collaboratori o disporre delle autorizzazioni corrispondenti.
Nota
Per i progetti pubblici, gli utenti a cui è concesso l'accesso degli stakeholder hanno accesso completo ad Azure Repos.
- I repository devono essere abilitati nel progetto. Se l'hub Repos e le pagine associate non vengono visualizzate, vedere Attivare o disattivare un servizio Azure DevOps per riabilitare Repos.
- Per visualizzare o esaminare le richieste pull, è necessario essere membri di un progetto Azure DevOps con accesso basic o versione successiva. Se non si è membri del progetto, viene aggiunto.
- Per contribuire a una richiesta pull, è necessario essere membri del gruppo di sicurezza Lettori o disporre delle autorizzazioni corrispondenti.
- Per creare e completare una richiesta pull, è necessario essere membri del gruppo di sicurezza Collaboratori o disporre delle autorizzazioni corrispondenti.
Per altre informazioni sulle autorizzazioni e l'accesso, vedere Repository Git predefinito e autorizzazioni di ramo e Informazioni sui livelli di accesso.
Feedback qualitativo per le richieste pull
Le revisioni di qualità elevata iniziano con feedback di qualità elevata. Ecco alcune chiavi per un ottimo feedback delle richieste pull:
- Il proprietario della richiesta pull deve avere le persone giuste per esaminare la richiesta pull e assicurarsi che i revisori sappiano cosa fa il codice.
- I revisori devono fornire feedback interattivo e costruttivo.
- I proprietari e i revisori devono commentare e rispondere rapidamente.
I proprietari delle richieste pull devono:
- Assicurarsi di selezionare i revisori corretti da assegnare a una richiesta pull.
- Includere revisori che conoscono il funzionamento del codice.
- Chiedere agli sviluppatori che lavorano in altre aree di condividere le proprie idee.
- Fornire una descrizione chiara delle modifiche.
- Fornire indicazioni per i revisori con i modelli di richiesta pull.
- Fornire una compilazione del codice con la correzione o la funzionalità in esecuzione.
- Rispondere ai commenti, accettare il suggerimento o spiegare perché la modifica suggerita non è ideale.
- Per suggerimenti validi all'esterno dell'ambito della richiesta pull, creare nuovi elementi di lavoro, rami e richieste pull per apportare tali modifiche.
I revisori devono eseguire le attività seguenti.
- Fornire commenti e suggerimenti sulle modifiche che non sono d'accordo con
- Identificare i problemi e fornire suggerimenti specifici su cosa fare in modo diverso
- Assicurarsi che il feedback abbia finalità chiare ed è facile da comprendere
- Lasciare commenti o votare le modifiche
Per altre informazioni, vedere Ottenere commenti e suggerimenti con le richieste pull Git.
Criteri di ramo e richieste pull
Il team potrebbe basarsi su rami critici nel repository, ad esempio il main ramo, per essere sempre in buone condizioni. È possibile impostare i criteri dei rami in modo che richiedano richieste pull per le modifiche apportate a questi rami protetti e rifiutare le modifiche apportate direttamente ai rami.
È possibile aggiungere altri criteri alle richieste pull per applicare una migliore qualità del codice nei rami chiave. Requisiti aggiuntivi come una compilazione pulita del codice proposto o l'approvazione da più revisori possono contribuire a proteggere i rami chiave.
È possibile impostare il numero di approvazioni necessarie per una richiesta pull in un criterio di ramo. È anche possibile impostare determinati revisori come obbligatori o facoltativi in tutte o in determinate richieste pull. È possibile impostare una richiesta pull per il completamento automatico con il numero richiesto di approvazioni, anche se altri revisori rifiutano le modifiche. Tuttavia, i revisori necessari devono approvare le richieste pull prima che le richieste pull possano essere unite. È consigliabile che almeno due revisori esaminino e approvino le modifiche in una richiesta pull significativa.
Per reimpostare i voti ogni volta che un autore della richiesta pull esegue il push di nuove modifiche, selezionare Reimposta i voti del revisore del codice quando sono presenti nuove modifiche nel criterio Richiedi un numero minimo di revisori del ramo.
La tabella seguente riepiloga i criteri che è possibile definire per personalizzare un ramo. Per una panoramica di tutti i criteri e le impostazioni dei repository e dei rami, vedere Impostazioni e criteri del repository Git.
Criteri
Predefinita
Descrizione
Disattivato
Richiedere l'approvazione da un numero specificato di revisori nelle richieste pull.
Disattivato
Incoraggiare la tracciabilità controllando la presenza di elementi di lavoro collegati nelle richieste pull
Disattivato
Verificare che tutti i commenti siano stati risolti nelle richieste pull.
Disattivato
Controllare la cronologia dei rami limitando i tipi di merge disponibili al termine delle richieste pull.
Disattivato
Aggiungere uno o più criteri per convalidare il codice mediante l'unione preliminare e la compilazione delle modifiche delle richieste pull. Può anche abilitare o disabilitare i criteri.
Disattivato
Aggiungere uno o più criteri per richiedere ad altri servizi di pubblicare lo stato corretto per completare le richieste pull. Può anche abilitare o disabilitare i criteri.
Disattivato
Aggiungere uno o più criteri per designare i revisori del codice da includere automaticamente quando le richieste pull modificano determinate aree di codice. Può anche abilitare o disabilitare i criteri.
Per altre informazioni, vedi:
- Panoramica dei criteri dei rami
- Come configurare i criteri dei rami
- Autorizzazioni per i rami
- Usare Funzioni di Azure per creare criteri ramo personalizzati
Definire i controlli di stato per migliorare la qualità del codice
Le richieste pull e i criteri dei rami consentono ai team di applicare le procedure consigliate per la revisione del codice e l'esecuzione di compilazioni automatizzate. Molti team hanno ulteriori requisiti e convalide da eseguire sul codice. Per soddisfare queste esigenze, è possibile integrare i controlli di stato delle richieste pull nel flusso di lavoro delle richieste pull. Con i controlli di stato della richiesta pull, i servizi esterni possono disconnettere a livello di codice le modifiche al codice associando le informazioni sull'esito positivo o negativo alla richiesta pull.
Per altre informazioni, vedere gli articoli seguenti:
- Personalizzare ed estendere i flussi di lavoro delle richieste pull con lo stato della richiesta pull
- Creare un server di stato della richiesta pull con Node.js
- Configurare un criterio ramo per un servizio esterno
Problema di base di unione multipla
In alcuni casi, una richiesta pull ha più di una vera base di merge e questa situazione può causare problemi di sicurezza. Se i file nella richiesta pull hanno versioni diverse tra le basi di merge, si genera un avviso che indica la presenza di una base di merge multipla. Per altre informazioni e correzione, vedere Più basi di merge.
Passaggi successivi
- Migliorare la qualità del codice con i criteri del ramo
- Personalizzare ed estendere i flussi di lavoro delle richieste pull con lo stato della richiesta pull
- Notifiche di aggiornamento delle richieste pull
- Modificare il ramo predefinito
- Copiare le modifiche con cherry-pick
- Strategie di unione e merge con squash
- Più basi di merge