Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Suggerimento
È possibile usare l'intelligenza artificiale per facilitare le attività di Azure DevOps. Per iniziare, vedere Abilitare l'assistenza AI con Azure DevOps MCP Server.
Gestire l'accesso ai repository per bloccare chi può contribuire al codice sorgente e gestire altre funzionalità. È possibile impostare le autorizzazioni per tutti i repository Git apportando modifiche alla voce Repository Git di primo livello. I singoli repository ereditano le autorizzazioni dalla voce Repository Git di primo livello.
Nota
I rami ereditano un subset di autorizzazioni dalle assegnazioni effettuate a livello di repository. Per le autorizzazioni e i criteri dei rami, vedere Impostare le autorizzazioni per i rami e Migliorare la qualità del codice con i criteri dei rami.
Per indicazioni su chi fornire livelli di autorizzazione maggiori, vedere Gestire l'accesso usando le autorizzazioni.
Prerequisiti
| Categoria | Requisiti |
|---|---|
| Accesso al progetto | Membro di un progetto. |
| Autorizzazioni | - Visualizzare il codice nei progetti privati: almeno livello di accesso Basic . - Clonare o contribuire al codice nei progetti privati: membro del gruppo di sicurezza Contributors o con le autorizzazioni corrispondenti nel progetto. - Impostare le autorizzazioni del ramo o del repository: le autorizzazioni di gestione sono autorizzazioni per il ramo o il repository. - Modifica ramo predefinito: i criteri di modifica sono autorizzazioni per il repository. - Importare un repository: membro del gruppo di sicurezza , amministratori del progetto, o del gruppo di sicurezza Git a livello di progetto , Crea repository impostato su Consenti. Per altre informazioni, vedere Impostare le autorizzazioni del repository Git. |
| Servizi | Repos abilitato. |
| Tools | Opzionale. Usare i comandi az repos: CLI di Azure DevOps. |
Nota
Nei progetti pubblici, gli utenti con accesso Stakeholder hanno pieno accesso ad Azure Repos, compresa la visualizzazione, la clonazione e il contribuire al codice.
| Categoria | Requisiti |
|---|---|
| Accesso al progetto | Membro di un progetto. |
| Autorizzazioni | - Visualizzare il codice: almeno accesso di base. - Clonare o contribuire al codice: membro del gruppo di sicurezza Contributor o autorizzazioni corrispondenti nel progetto. |
| Servizi | Repos abilitato. |
Per contribuire al codice sorgente, è necessario un livello di accesso basic o superiore. Gli utenti a cui viene concesso l'accesso stakeholder per i progetti privati non hanno accesso al codice sorgente. Gli utenti a cui viene concesso l'accesso stakeholder per i progetti pubblici hanno lo stesso accesso dei collaboratori e degli utenti a cui è concesso l'accesso di base . Per altre informazioni, vedere Informazioni sui livelli di accesso.
Per contribuire al codice sorgente, è necessario un livello di accesso basic o superiore. Gli utenti a cui viene concesso l'accesso stakeholder non hanno accesso al codice sorgente. Per altre informazioni, vedere Informazioni sui livelli di accesso.
Autorizzazioni predefinite per il repository
Per impostazione predefinita, i membri del gruppo Collaboratori del progetto dispongono delle autorizzazioni per contribuire a un repository. Questo livello di autorizzazione include la possibilità di creare rami, creare tag e gestire le note. Per una descrizione di ogni gruppo di sicurezza e livello di autorizzazione, vedere Informazioni di riferimento su autorizzazioni e gruppi.
Autorizzazione
Lettori
Collaboratori
Amministratori di build
Project Admins
Lettura (clonazione, recupero ed esplorazione del contenuto di un repository); inoltre, può creare, commentare, votare e contribuire alle richieste pull
✔️
✔️
✔️
✔️
Contribuire, Creare branche, Creare tag e Gestire le note
✔️
✔️
✔️
Creare repository, eliminare repository e rinominare il repository
✔️
Modificare i criteri, gestire le autorizzazioni, rimuovere i blocchi di altri utenti
✔️
Ignorare i criteri quando si completano le richieste pull, ignorare i criteri durante il push, Effettuare un push forzato (riscrivere la cronologia, eliminare branch e tag)
(non impostato per alcun gruppo di sicurezza)
A partire da Azure DevOps sprint 224 (Azure DevOps Services e Azure DevOps Server 2022.1 e versioni successive), l'autorizzazione Modifica criteri non viene più concessa automaticamente ai creatori di rami. In precedenza, quando si creava un nuovo ramo, si riceveva l'autorizzazione per modificare i criteri in tale ramo.
Con questo aggiornamento, il comportamento predefinito è cambiato. Questa autorizzazione non viene concessa anche se l'impostazione Gestione autorizzazioni è attivata per il repository. È necessario disporre dell'autorizzazione Modifica criteri concessa in modo esplicito (manualmente o tramite l'API REST) dall'ereditarietà delle autorizzazioni di sicurezza o tramite un'appartenenza a un gruppo.
Aprire la sicurezza per un repository
È possibile impostare le autorizzazioni di un repository Git da Impostazioni del Progetto>Repository.
Aprire il portale Web e selezionare il progetto in cui si desidera aggiungere utenti o gruppi. Per selezionare un altro progetto, vedere Cambiare progetto, repository, team.
Seleziona Impostazioni del progetto>Repository.
Per impostare le autorizzazioni per tutti i repository Git, selezionare Sicurezza.
Per impostare le autorizzazioni per un repository specifico, selezionare il repository e quindi selezionare Sicurezza.
Impostare le autorizzazioni per un repository
È possibile gestire l'accesso a un repository impostando lo stato di autorizzazione su Consenti o Nega per un singolo utente o un gruppo di sicurezza.
Aprire il portale Web e selezionare il progetto in cui si desidera aggiungere utenti o gruppi. Per selezionare un altro progetto, vedere Cambiare progetto, repository, team.
Seleziona Impostazioni del progetto>Repository.
Per impostare le autorizzazioni per tutti i repository Git per un progetto, selezionare Repository Git e quindi selezionare il gruppo di sicurezza le cui autorizzazioni si desidera gestire. Ad esempio, selezionare Collaboratori e quindi selezionare l'autorizzazione per Crea repository.
Per visualizzare l'immagine completa, fare clic sull'immagine da espandere. Scegli l'icona
per chiudere.
Nota
Potrebbe non essere possibile trovare un utente da una pagina di autorizzazioni o da un campo di identità se l'utente non è stato aggiunto al progetto aggiungendolo a un gruppo di sicurezza o a un team di progetto. Inoltre, quando un utente viene aggiunto a Microsoft Entra ID o Active Directory, può verificarsi un ritardo tra il momento in cui vengono aggiunti al progetto e quando è possibile eseguire la ricerca da un campo identity. Il ritardo può essere compreso tra 5 minuti e 7 giorni.
In caso contrario, selezionare un repository specifico e selezionare il gruppo di sicurezza le cui autorizzazioni si desidera gestire.
Nota
È possibile aggiungere un utente o un gruppo e non modificare le autorizzazioni per tale utente o gruppo. Dopo l'aggiornamento della pagina delle autorizzazioni, l'utente o il gruppo non viene più visualizzato.
Seleziona Salva modifiche.
Modificare le autorizzazioni per un gruppo di sicurezza
Per impostare le autorizzazioni per un gruppo di sicurezza personalizzato, è necessario definire in precedenza tale gruppo. Per altre informazioni, vedere Change project-level permissions.
Per impostare le autorizzazioni per un gruppo specifico, selezionare il gruppo. Ad esempio, selezionare Collaboratori.
Modificare una o più autorizzazioni. Per concedere le autorizzazioni, modificare Non impostato in Consenti. Per limitare le autorizzazioni, modificare Consenti su Nega.
Le modifiche alle autorizzazioni vengono salvate automaticamente per il gruppo selezionato.
Impostare le autorizzazioni per un utente specifico
Per impostare le autorizzazioni per un utente specifico, immettere il nome dell'utente nel filtro di ricerca e selezionare le identità visualizzate.
Apportare le modifiche al set di autorizzazioni.
Nota
Potrebbe non essere possibile trovare un utente da una pagina di autorizzazioni o da un campo di identità se l'utente non è stato aggiunto al progetto aggiungendolo a un gruppo di sicurezza o a un team di progetto. Inoltre, quando un utente viene aggiunto a Microsoft Entra ID o Active Directory, può verificarsi un ritardo tra il momento in cui vengono aggiunti al progetto e quando è possibile eseguire la ricerca da un campo identity. Il ritardo può essere compreso tra 5 minuti e 7 giorni.
Le modifiche alle autorizzazioni vengono salvate automaticamente per il gruppo selezionato.
È possibile aggiungere un utente o un gruppo e non modificare le autorizzazioni per tale utente o gruppo. Dopo l'aggiornamento della pagina delle autorizzazioni, l'utente o il gruppo non viene più visualizzato.
Abilitare o disabilitare l'ereditarietà per un repository specifico
Per abilitare o disabilitare l'ereditarietà per un repository specifico, selezionare il repository e quindi spostare il dispositivo di scorrimento Ereditarietà nella posizione attiva o disattivata.
[!div class="mx-imgBorder"] 
Per informazioni sull'ereditarietà, vedere Informazioni su autorizzazioni e gruppi.
Esonerare dall'applicazione delle politiche e aggirare le autorizzazioni delle politiche
Esistono molti scenari in cui si ha la necessità occasionale di ignorare un criterio di ramo. Alcuni esempi sono quando si ripristina una modifica che ha causato un'interruzione di compilazione o si applica un hotfix durante la notte.
In precedenza, l'autorizzazione esente dall'applicazione delle politiche ha consentito ai team di gestire gli utenti a cui è stata concessa la possibilità di ignorare le politiche di ramo al termine di una pull request. Tuttavia, tale autorizzazione ha anche concesso agli utenti la possibilità di fare il push direttamente nel ramo e ignorare completamente il processo di pull request.
L'autorizzazione esente dall'applicazione delle politiche offre ora un maggiore controllo ai team che concedono permessi di deroga. Le due autorizzazioni seguenti sostituiscono l'autorizzazione precedente:
- Ignorare i criteri durante il completamento delle richieste pull: gli utenti con questa autorizzazione possono usare l'esperienza di override per le richieste pull.
- Ignorare le politiche durante il push: gli utenti con questa autorizzazione possono eseguire il push direttamente sui branch con le politiche necessarie configurate.
È possibile usare l'opzione bypass quando necessario concedendo la prima autorizzazione e negando il secondo. È comunque possibile proteggere dal push accidentale in un ramo con criteri.
Nota
Questa modifica non introduce modifiche al comportamento. Agli utenti a cui era stato concesso in precedenza Consenti per esenzione dall'applicazione delle politiche viene ora concesso Consenti per le due nuove autorizzazioni. Possono eseguire l'override del completamento dei pull request e eseguire il push direttamente nei rami con criteri.