Criteri e impostazioni dei rami

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

I criteri dei rami aiutano i team a proteggere i rami importanti dello sviluppo. I criteri applicano gli standard di gestione del codice e della qualità del codice del team. Questo articolo descrive come impostare e gestire i criteri dei rami. Per una panoramica di tutti i criteri e le impostazioni dei repository e dei rami, vedere Impostazioni e criteri del repository Git.

Un ramo con i criteri necessari configurati non può essere eliminato e richiede richieste pull per tutte le modifiche.

Prerequisiti

  • Per impostare i criteri di ramo, è necessario essere membri del gruppo di sicurezza Amministratori progetto o disporre delle autorizzazioni Modifica criteri a livello di repository. Per altre informazioni, vedere Impostare le autorizzazioni del repository Git.

Configurare i criteri per i rami

Per gestire i criteri dei rami, selezionare Repos>Branch per aprire la pagina Rami nel portale Web.

Screenshot che mostra la voce di menu Rami.

È anche possibile accedere alle impostazioni dei criteri di ramo con Project Settings Repository Policies Branch Name .You can also get to branch policy settings with Project Settings>Repository>Policies><>Branch Name.>

I rami con criteri visualizzano un'icona dei criteri. È possibile selezionare l'icona per passare direttamente alle impostazioni dei criteri del ramo.

Per impostare i criteri di ramo, individuare il ramo che si vuole gestire. È possibile esplorare l'elenco o cercare il ramo nella casella Nome ramo di ricerca in alto a destra.

Selezionare l'icona Altre opzioni accanto al ramo e quindi selezionare Criteri ramo dal menu di scelta rapida.

Screenshot che mostra Apri i criteri dei rami dal menu di scelta rapida.

Individuare il ramo nella pagina. È possibile esplorare l'elenco oppure cercare il ramo usando la casella Cerca tutti i rami in alto a destra.

Screenshot che mostra la pagina Rami.

Selezionare il pulsante ... . Selezionare Branch policies (Criteri ramo) dal menu di scelta rapida.

Screenshot che mostra Apri i criteri dei rami dal menu di scelta rapida.

Configurare i criteri nella pagina delle impostazioni del ramo. Vedere le sezioni seguenti per le descrizioni e le istruzioni per ogni tipo di criterio.

Configurare i criteri nella pagina Criteri . Vedere le sezioni seguenti per le descrizioni di ogni tipo di criterio. Selezionare Salva modifiche per applicare la nuova configurazione dei criteri.

Screenshot che mostra la scheda Criteri.

Richiedere un numero minimo di revisori

Le revisioni del codice sono importanti per i progetti di sviluppo software. Per assicurarsi che i team esaminino e approvino le richieste pull, è possibile richiedere l'approvazione da un numero minimo di revisori. I criteri di base richiedono che un numero specificato di revisori approvi il codice, senza rifiuto.

Per impostare i criteri, in Criteri di ramo impostare Richiedi un numero minimo di revisori su Sì. Immettere il numero richiesto di revisori e selezionare una delle opzioni seguenti:

Screenshot che mostra il criterio Abilita il criterio Richiedi revisioni codice.

  • Selezionare Consenti ai richiedenti di approvare le proprie modifiche per consentire all'autore di una richiesta pull di votarne l'approvazione. In caso contrario, l'autore può comunque votare Approva per la richiesta pull, ma il loro voto non viene conteggiato per il numero minimo di revisori.

  • Selezionare Impedisci al pusher più recente di approvare le proprie modifiche per applicare la separazione dei compiti. Per impostazione predefinita, chiunque disponga dell'autorizzazione push nel ramo di origine può aggiungere commit e votare l'approvazione della richiesta pull. Se si seleziona questa opzione, il voto del pusher più recente non viene conteggiato, anche se in genere può approvare le proprie modifiche.

  • Selezionare Consenti completamento anche se alcuni revisori votano per attendere o rifiutare il completamento della richiesta pull anche se alcuni revisori votano contro l'approvazione. Il numero minimo di revisori deve comunque approvare.

  • In Quando viene eseguito il push di nuove modifiche:
    • Selezionare Richiedi almeno un'approvazione nell'ultima iterazione per richiedere almeno un voto di approvazione per l'ultima modifica del ramo di origine.
    • Selezionare Reimposta tutti i voti di approvazione (non reimposta i voti per rifiutare o attendere) per rimuovere tutti i voti di approvazione, ma mantenere i voti da rifiutare o attendere ogni volta che il ramo di origine cambia.
    • Selezionare Reimposta tutti i voti del revisore del codice per rimuovere tutti i voti dei revisori ogni volta che il ramo di origine cambia, inclusi i voti da approvare, rifiutare o attendere.
  • In Quando viene eseguito il push di nuove modifiche:
    • Selezionare Richiedi almeno un'approvazione per ogni iterazione per richiedere almeno un voto di approvazione per l'ultima modifica del ramo di origine. L'approvazione dell'utente non viene conteggiata rispetto a qualsiasi iterazione precedente non approvata di cui è stato eseguito il push da tale utente. Di conseguenza, è necessaria un'altra approvazione per l'ultima iterazione da parte di un altro utente. Richiedere almeno un'approvazione per ogni iterazione è disponibile in Azure DevOps Server 2022.1 e versioni successive.
    • Selezionare Richiedi almeno un'approvazione nell'ultima iterazione per richiedere almeno un voto di approvazione per l'ultima modifica del ramo di origine.
    • Selezionare Reimposta tutti i voti di approvazione (non reimposta i voti per rifiutare o attendere) per rimuovere tutti i voti di approvazione, ma mantenere i voti da rifiutare o attendere ogni volta che il ramo di origine cambia.
    • Selezionare Reimposta tutti i voti del revisore del codice per rimuovere tutti i voti dei revisori ogni volta che il ramo di origine cambia, inclusi i voti da approvare, rifiutare o attendere.

Selezionare la casella Richiedi revisioni codice

  • Se i richiedenti possono approvare le proprie modifiche non è selezionato, l'autore della richiesta pull può comunque votare Approva per la richiesta pull, ma il voto non viene conteggiato per il numero minimo di revisori.
  • Se un revisore rifiuta le modifiche, la richiesta pull non può essere completata a meno che non si selezioni Consenti completamento anche se alcuni revisori votano per attendere o rifiutare.
  • È possibile reimpostare i voti del revisore del codice quando viene eseguito il push di nuove modifiche nel ramo di origine. Selezionare Reimposta voti revisore del codice quando sono presenti nuove modifiche.

Se tutti gli altri criteri vengono superati, l'autore può completare la richiesta pull quando il numero richiesto di revisori lo approva.

Verificare la presenza di elementi di lavoro collegati

Per il rilevamento della gestione degli elementi di lavoro, è possibile richiedere associazioni tra le richieste pull e gli elementi di lavoro. Il collegamento degli elementi di lavoro offre più contesto per le modifiche e garantisce che gli aggiornamenti vengano sottoposti al processo di rilevamento degli elementi di lavoro.

Per impostare i criteri, in Criteri di ramo impostare Verifica la presenza di elementi di lavoro collegati su Sì. Questa impostazione richiede che gli elementi di lavoro siano collegati a una richiesta pull per il merge della richiesta pull. Impostare l'impostazione Facoltativo per avvisare quando non sono presenti elementi di lavoro collegati, ma consentire il completamento della richiesta pull.

Screenshot della richiesta di elementi di lavoro collegati nelle richieste pull.

Richiedere elementi di lavoro collegati nelle richieste pull

Verificare la risoluzione dei commenti

Il criterio Verifica la risoluzione dei commenti controlla se tutti i commenti delle richieste pull vengono risolti.

Configurare un criterio di risoluzione dei commenti per il ramo impostando Verifica la risoluzione dei commenti su Sì. Selezionare quindi se impostare il criterio Obbligatorio o Facoltativo.

Screenshot di Verifica la risoluzione dei commenti.

Per altre informazioni sull'uso dei commenti delle richieste pull, vedere Esaminare le richieste pull.

Configurare un criterio di risoluzione dei commenti per il ramo selezionando Verifica la risoluzione dei commenti.

Verificare la risoluzione dei commenti

Per altre informazioni sull'uso dei commenti delle richieste pull, vedere Esaminare le richieste pull.

Limitare i tipi di unione

Azure Repos include diverse strategie di merge e, per impostazione predefinita, sono consentite tutte. È possibile mantenere una cronologia coerente dei rami applicando una strategia di merge per il completamento della richiesta pull.

Impostare Limita tipi di unione su Sì per limitare i tipi di unione da consentire nel repository.

Screenshot di Limit merge types (Limita tipi di unione).

  • L'unione di base (senza fast-forward) crea un commit di merge nella destinazione i cui elementi padre sono i rami di destinazione e di origine.
  • L'unione di squash crea una cronologia lineare con un singolo commit nel ramo di destinazione con le modifiche del ramo di origine. Altre informazioni sull'unione di squash e su come influisce sulla cronologia dei rami.
  • Rebase e fast-forward crea una cronologia lineare riproducendo i commit di origine nel ramo di destinazione senza commit di merge.
  • La rebase con commit di merge riproduce i commit di origine nella destinazione e crea anche un commit di merge.

Nota

Questa funzionalità è disponibile per Azure DevOps Server 2020 e versioni successive.

Applicare una strategia di unione

Mantenere una cronologia coerente dei rami applicando una strategia di merge al termine di una richiesta pull. Selezionare Imponi una strategia di merge e selezionare un'opzione per richiedere che le richieste pull vengano unite usando tale strategia.

Impostare i requisiti di unione

  • Nessuna unione rapida: questa opzione unisce la cronologia dei commit del ramo di origine quando la richiesta pull si chiude e crea un commit di merge nel ramo di destinazione.
  • Merge di squash: completare tutte le richieste pull con un merge di squash, creando un singolo commit nel ramo di destinazione con le modifiche dal ramo di origine. Altre informazioni sull'unione di squash e su come influisce sulla cronologia dei rami.

Convalida compilazione

È possibile impostare un criterio che richiede modifiche della richiesta pull per la compilazione corretta prima del completamento della richiesta pull. I criteri di compilazione riducono le interruzioni e mantengono i risultati dei test superati. I criteri di compilazione consentono anche se si usa l'integrazione continua nei rami di sviluppo per rilevare i problemi in anticipo.

Un criterio di convalida della compilazione accoda una nuova compilazione quando viene creata una nuova richiesta pull o le modifiche vengono inoltrate a una richiesta pull esistente destinata al ramo. I criteri di compilazione valutano i risultati della compilazione per determinare se la richiesta pull può essere completata.

Importante

Prima di specificare un criterio di convalida della compilazione, è necessario disporre di una pipeline di compilazione. Se non si ha una pipeline, vedere Creare una pipeline di compilazione. Scegliere il tipo di compilazione corrispondente al tipo di progetto.

Per aggiungere un criterio di convalida della compilazione

  1. Selezionare il + pulsante accanto a Convalida compilazione.

    Screenshot che mostra il pulsante Aggiungi accanto a Convalida compilazione.

  2. Compilare il modulo Imposta criteri di compilazione :

    Screenshot delle impostazioni dei criteri di compilazione.

    • Selezionare la pipeline di compilazione.

    • Facoltativamente, impostare un filtro Percorso. Altre informazioni sui filtri di percorso nei criteri dei rami.

    • In Trigger selezionare Automatico (ogni volta che il ramo di origine viene aggiornato) o Manuale.

    • In Requisito dei criteri selezionare Obbligatorio o Facoltativo. Se si sceglie Obbligatorio, le compilazioni devono essere completate correttamente per completare le richieste pull. Scegliere Facoltativo per fornire una notifica dell'errore di compilazione, ma consentire comunque il completamento delle richieste pull.

    • Impostare una scadenza della compilazione per assicurarsi che gli aggiornamenti al ramo protetto non interrompano le modifiche per le richieste pull aperte.

      • Immediatamente quando <viene aggiornato il nome> del ramo: questa opzione imposta lo stato dei criteri di compilazione della richiesta pull su non riuscita ogni volta che il ramo viene aggiornato e accoda nuovamente una compilazione. Questa impostazione garantisce che la richiesta pull venga modificata correttamente anche se il ramo protetto cambia.

        Questa opzione è ideale per i team i cui rami importanti hanno poche modifiche. I team che lavorano in rami di sviluppo occupati potrebbero riscontrare interruzioni nell'attesa di una compilazione ogni volta che il ramo viene aggiornato.

      • Dopo <n> ore se <il nome> del ramo è stato aggiornato: questa opzione scade lo stato corrente dei criteri quando il ramo protetto viene aggiornato se la compilazione passata è precedente alla soglia immessa. Questa opzione è un compromesso tra sempre o mai richiedere una compilazione quando il ramo protetto viene aggiornato. Questa scelta riduce il numero di compilazioni quando il ramo protetto ha aggiornamenti frequenti.

      • Mai: gli aggiornamenti al ramo protetto non modificano lo stato dei criteri. Questo valore riduce il numero di compilazioni, ma può causare problemi durante il completamento delle richieste pull non aggiornate di recente.

    • Immettere un nome visualizzato facoltativo per questo criterio di compilazione. Questo nome identifica i criteri nella pagina Criteri ramo . Se non si specifica un nome visualizzato, il criterio usa il nome della pipeline di compilazione.

  3. Seleziona Salva.

Quando il proprietario della richiesta pull effettua il push delle modifiche che vengono compilate correttamente, lo stato dei criteri viene aggiornato.

Se si dispone di un valore Immediatamente quando <il nome> del ramo viene aggiornato o Dopo <n> ore se <il nome> del ramo è stato aggiornato, lo stato dei criteri viene aggiornato quando il ramo protetto viene aggiornato, se la compilazione precedente non è più valida.

Nota

Questa funzionalità è disponibile per Azure DevOps Server 2020 e versioni successive.

Impostare un criterio che richiede modifiche in una richiesta pull per la compilazione con il ramo protetto prima che la richiesta pull possa essere completata. I criteri di compilazione riducono le interruzioni e mantengono i risultati dei test superati. I criteri di compilazione consentono anche se si usa l'integrazione continua nei rami di sviluppo per rilevare i problemi in anticipo.

Se è abilitato un criterio di convalida della compilazione, una nuova compilazione viene accodata quando viene creata una nuova richiesta pull o quando vengono eseguite il push delle modifiche a una richiesta pull esistente destinata al ramo. I criteri di compilazione valutano quindi i risultati della compilazione per determinare se la richiesta pull può essere completata.

Importante

Prima di specificare un criterio di convalida della compilazione, è necessario avere una definizione di compilazione. Se non è disponibile, vedere Creare una definizione di compilazione e scegliere il tipo di compilazione corrispondente al tipo di progetto.

Aggiungere criteri di compilazione

Scegliere Aggiungi criteri di compilazione e configurare le opzioni in Aggiungi criteri di compilazione.

Impostazioni dei criteri di compilazione

  1. Selezionare la definizione di compilazione.

  2. Scegliere il tipo di trigger. Selezionare Automatico (ogni volta che il ramo di origine viene aggiornato) o Manuale.

  3. Selezionare il requisito criteri. Se si sceglie Obbligatorio, le compilazioni devono essere completate correttamente per completare le richieste pull. Scegliere Facoltativo per fornire una notifica dell'errore di compilazione, ma consentire comunque il completamento delle richieste pull.

  4. Impostare una scadenza della compilazione per assicurarsi che gli aggiornamenti al ramo protetto non interrompano le modifiche per le richieste pull aperte.

    • Immediatamente quando branch name viene aggiornato: questa opzione imposta lo stato dei criteri di compilazione in una richiesta pull non riuscita quando il ramo protetto viene aggiornato. Ripetere la coda di una compilazione per aggiornare lo stato di compilazione. Questa impostazione garantisce che le modifiche apportate alle richieste pull vengano compilate correttamente anche quando il ramo protetto cambia. Questa opzione è ideale per i team che dispongono di rami importanti con un volume inferiore di modifiche. I team che lavorano in rami di sviluppo occupati potrebbero riscontrare interruzioni nell'attesa del completamento di una compilazione ogni volta che il ramo protetto viene aggiornato.
    • Dopo n ore se branch name è stato aggiornato: questa opzione scade lo stato corrente dei criteri quando il ramo protetto viene aggiornato se la compilazione passing è precedente alla soglia immessa. Questa opzione è un compromesso tra la richiesta di una compilazione sempre quando il ramo protetto viene aggiornato e non ne richiede mai uno. Questa scelta è eccellente per ridurre il numero di build quando il ramo protetto ha aggiornamenti frequenti.
    • Mai: gli aggiornamenti al ramo protetto non modificano lo stato dei criteri. Questo valore riduce il numero di compilazioni per il ramo. Può causare problemi durante la chiusura delle richieste pull non aggiornate di recente.

  5. Immettere un nome visualizzato facoltativo per questo criterio di compilazione. Questo nome identifica i criteri nella pagina Criteri ramo . Se non si specifica un nome visualizzato, il criterio usa il nome della definizione di compilazione.

  6. Seleziona Salva.

Quando il proprietario esegue il push delle modifiche che vengono compilate correttamente, lo stato dei criteri viene aggiornato. Se si dispone di un valore Immediatamente quando branch name viene aggiornato o Dopo n ore se branch name è stato scelto un criterio di compilazione aggiornato , lo stato dei criteri viene aggiornato quando il ramo protetto viene aggiornato se la build più recente non è più valida.

Controlli di stato

I servizi esterni possono usare l'API Stato richiesta pull per pubblicare lo stato dettagliato delle richieste pull. I criteri di ramo per servizi aggiuntivi consentono a tali servizi esterni di partecipare al flusso di lavoro della richiesta pull e di stabilire i requisiti dei criteri.

Screenshot di Richiedi servizi esterni da approvare.

Per istruzioni sulla configurazione di questo criterio, vedere Configurare un criterio di ramo per un servizio esterno.

Richiedere l'approvazione da servizi esterni

I servizi esterni possono usare l'API Stato richiesta pull per pubblicare lo stato dettagliato delle richieste pull. I criteri di ramo per servizi aggiuntivi consentono a tali servizi esterni di partecipare al flusso di lavoro della richiesta pull e di stabilire i requisiti dei criteri.

Richiedere l'approvazione di servizi esterni

Per istruzioni sulla configurazione di questo criterio, vedere Configurare un criterio di ramo per un servizio esterno.

Includi automaticamente revisori del codice

È possibile aggiungere automaticamente revisori alle richieste pull che modificano i file in directory e file specifici o a tutte le richieste pull in un repository.

  1. Selezionare il + pulsante accanto a Revisori inclusi automaticamente.

    Screenshot che mostra l'opzione Aggiungi revisori obbligatori.

  2. Compilare la schermata Aggiungi nuovi criteri revisori.

    Screenshot che mostra la schermata Aggiungi nuovi criteri di revisore.

    • Aggiungere utenti e gruppi ai revisori.

    • Selezionare Facoltativo se si desidera aggiungere automaticamente i revisori, ma non richiedere l'approvazione per completare la richiesta pull.

      In alternativa, selezionare Obbligatorio se le richieste pull non possono essere completate fino a quando:

      • Ogni utente aggiunto come revisore approva le modifiche.
      • Almeno una persona in ogni gruppo aggiunta come revisore approva le modifiche.
      • Se è necessario un solo gruppo, il numero minimo di membri specificati approva le modifiche.

    • Specificare i file e le cartelle che richiedono i revisori inclusi automaticamente. Lasciare vuoto questo campo per richiedere i revisori per tutte le richieste pull nel ramo.

    • Selezionare Consenti ai richiedenti di approvare le proprie modifiche se i proprietari delle richieste pull possono votare per approvare le proprie richieste pull per soddisfare questo criterio.

    • È possibile specificare un messaggio del feed attività visualizzato nella richiesta pull.

  3. Seleziona Salva.

Nota

Questa funzionalità è disponibile per Azure DevOps Server 2020 e versioni successive.

Selezionare i revisori per directory e file specifici nel repository.

Immettere il percorso e i revisori necessari

Questi revisori vengono aggiunti automaticamente alle richieste pull che modificano i file lungo tali percorsi. È anche possibile specificare un messaggio del feed attività.

Aggiungere revisori automatici

Se si seleziona Obbligatorio, la richiesta pull non può essere completata fino a quando:

  • Ogni utente aggiunto come revisore per il percorso approva le modifiche.
  • Almeno una persona in ogni gruppo aggiunto al percorso approva le modifiche.
  • Il numero di revisori specificati per ogni gruppo aggiunto al percorso approva le modifiche.

I revisori necessari vengono aggiunti automaticamente

Selezionare Facoltativo se si desidera aggiungere automaticamente i revisori, ma non richiedere l'approvazione per completare la richiesta pull.

È possibile selezionare I richiedenti possono approvare le proprie modifiche.

Quando tutti i revisori necessari approvano il codice, è possibile completare la richiesta pull.

Lo stato della richiesta pull indica che i revisori hanno approvato

Ignorare i criteri dei rami

In alcuni casi, potrebbe essere necessario ignorare i requisiti dei criteri. Le autorizzazioni di bypass consentono di eseguire direttamente il push delle modifiche in un ramo o di completare le richieste pull che non soddisfano i criteri dei rami. È possibile concedere autorizzazioni di bypass a un utente o a un gruppo. È possibile definire l'ambito delle autorizzazioni di bypass per un intero progetto, un repository o un singolo ramo.

Due autorizzazioni consentono agli utenti di ignorare i criteri di ramo in modi diversi:

  • I criteri di bypass quando si completano le richieste pull si applicano solo al completamento della richiesta pull. Gli utenti con questa autorizzazione possono completare le richieste pull anche se le richieste pull non soddisfano i criteri.

  • Ignorare i criteri quando si esegue il push si applica ai push dai repository locali e alle modifiche apportate sul Web. Gli utenti con questa autorizzazione possono eseguire il push delle modifiche direttamente nei rami protetti senza soddisfare i requisiti dei criteri.

Screenshot che mostra le autorizzazioni di imposizione dei criteri di bypass.

Per altre informazioni sulla gestione di queste autorizzazioni, vedere Autorizzazioni Git.

In TFS 2015 fino a TFS 2018 Update 2, l'autorizzazione esentata dall'imposizione dei criteri consente agli utenti con questa autorizzazione di eseguire le azioni seguenti:

  • Acconsentire esplicitamente all'override dei criteri e completare una richiesta pull anche se il set corrente di criteri di ramo non è soddisfatto.
  • Eseguire il push direttamente in un ramo anche se il ramo dispone di criteri di ramo impostati. Quando un utente con questa autorizzazione esegue un push che esegue l'override dei criteri di ramo, il push ignora automaticamente i criteri di ramo senza alcun passaggio o avviso di consenso esplicito.

Importante

Prestare attenzione quando si concede la possibilità di ignorare i criteri, in particolare a livello di repository e progetto. I criteri sono un elemento fondamentale della gestione sicura e conforme del codice sorgente.

Filtri di percorso

Diversi criteri di ramo offrono filtri di percorso. Se viene impostato un filtro di percorso, il criterio si applica solo ai file che corrispondono al filtro del percorso. Lasciare vuoto questo campo significa che il criterio si applica a tutti i file nel ramo.

È possibile specificare percorsi assoluti (il percorso deve iniziare da o da / un carattere jolly) e i caratteri jolly. Esempi:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

È possibile specificare più percorsi usando ; come separatore. Esempio:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

I percorsi preceduti ! da vengono esclusi se altrimenti verrebbero inclusi. Esempio:

  • /WebApp/*;!/WebApp/Tests/* include tutti i file in /WebApp ad eccezione dei file in /WebApp/Tests
  • !/WebApp/Tests/* non specifica alcun file, poiché non è incluso alcun elemento per primo

L'ordine dei filtri è significativo. I filtri vengono applicati da sinistra a destra.

Domande e risposte

È possibile eseguire il push delle modifiche direttamente nei rami con criteri di ramo?

Non è possibile eseguire il push delle modifiche direttamente ai rami con i criteri di ramo necessari , a meno che non si disponga delle autorizzazioni per ignorare i criteri dei rami. Le modifiche apportate a questi rami possono essere apportate solo tramite richieste pull. È possibile eseguire il push delle modifiche direttamente ai rami con criteri di ramo facoltativi , se non hanno criteri di ramo obbligatori.

Che cos'è il completamento automatico?

Le richieste pull nei rami con i criteri di ramo configurati hanno il pulsante Imposta completamento automatico. Selezionare questa opzione per completare automaticamente la richiesta pull dopo aver soddisfatto tutti i criteri. Il completamento automatico è utile quando non si prevedono problemi con le modifiche.

Quando vengono controllate le condizioni dei criteri del ramo?

I criteri dei rami rivalutano nel server quando i proprietari delle richieste pull eseggono le modifiche e quando i revisori votano. Se un criterio attiva una compilazione, lo stato della compilazione viene impostato su in attesa fino al completamento della compilazione.

È possibile usare le definizioni di compilazione XAML nei criteri di ramo?

No, non è possibile usare le definizioni di compilazione XAML nei criteri di ramo.

Quali caratteri jolly è possibile usare per i revisori del codice necessari?

I singoli asterischi * corrispondono a un numero qualsiasi di caratteri, incluse le barre / e le barre rovesciata \. I punti interrogativi ? corrispondono a qualsiasi singolo carattere.

Esempi:

  • *.sql corrisponde a tutti i file con l'estensione .sql .
  • /ConsoleApplication/* corrisponde a tutti i file nella cartella denominata ConsoleApplication.
  • /.gitattributes corrisponde al file .gitattributes* nella radice del repository.
  • */.gitignore corrisponde a qualsiasi file con estensione gitignore nel repository.

I percorsi dei revisori del codice necessari fanno distinzione tra maiuscole e minuscole?

No, i criteri dei rami non fanno distinzione tra maiuscole e minuscole.

Come è possibile configurare più utenti come revisori necessari, ma è necessario solo uno di essi per approvare?

È possibile aggiungere gli utenti a un gruppo e quindi aggiungere il gruppo come revisore. Qualsiasi membro del gruppo può quindi approvare per soddisfare i requisiti dei criteri.

Sono disponibili autorizzazioni per i criteri di bypass. Perché vengono visualizzati ancora errori dei criteri nello stato della richiesta pull?

I criteri configurati vengono sempre valutati per le modifiche delle richieste pull. Per gli utenti che dispongono di autorizzazioni per i criteri di bypass, lo stato dei criteri segnalato è solo avviso. Se l'utente con autorizzazioni di bypass approva, lo stato di errore non blocca il completamento della richiesta pull.

Perché non è possibile completare le proprie richieste pull quando si imposta "Consenti ai richiedenti di approvare le proprie modifiche"?

Sia il criterio Richiedi un numero minimo di revisori che il criterio Revisori inclusi automaticamente hanno le opzioni Consenti ai richiedenti di approvare le proprie modifiche. In ogni criterio, l'impostazione si applica solo a tale criterio. L'impostazione non influisce sugli altri criteri.

Ad esempio, per la richiesta pull sono impostati i criteri seguenti:

  • Richiedere un numero minimo di revisori richiede almeno un revisore.
  • I revisori inclusi automaticamente richiedono l'utente o un team in cui ci si trova come revisore.
  • I revisori inclusi automaticamente hanno Consenti ai richiedenti di approvare le proprie modifiche abilitate.
  • Richiedere un numero minimo di revisori non dispone di Consenti ai richiedenti di approvare le proprie modifiche abilitate.

In questo caso, l'approvazione soddisfa i revisori inclusi automaticamente, ma non Richiedi un numero minimo di revisori, quindi non è possibile completare la richiesta pull.

Potrebbero essere presenti anche altri criteri, ad esempio Impedisci al push più recente di approvare le proprie modifiche, che impediscono l'approvazione delle proprie modifiche anche se è impostata l'opzione Consenti ai richiedenti di approvare le proprie modifiche .

Cosa accade quando il percorso nei filtri di percorso non inizia con / o con un carattere jolly?

Il percorso nei filtri di percorso che non inizia con / o con un carattere jolly non ha alcun effetto e il filtro di percorso valuta come se tale percorso non fosse specificato. Un percorso di questo tipo non può corrispondere al percorso assoluto del / file inizia con .