Impostare autorizzazioni del repository Git
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
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 autorizzazioni corrispondenti nel progetto. - Impostare le autorizzazioni per il ramo o il repository: Gestisci le autorizzazioni per il ramo o il repository. - Modificare il ramo predefinito: Modificare le politiche le 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. |
| Strumenti | Opzionale. Usare i comandi az repos: l'interfaccia della riga di comando 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 avere un livello di accesso di base o superiore. Agli utenti a cui è stato concesso accesso come Stakeholder per progetti privati non hanno accesso al codice sorgente. Utenti a cui è stato concesso l'accesso come Stakeholder per i progetti pubblici hanno lo stesso accesso dei Collaboratori e di quelli a cui è stato concesso l'accesso di base. Per altre informazioni, vedere Informazioni sui livelli di accesso.
Per contribuire al codice sorgente, è necessario avere un livello di accesso di base o superiore. Gli utenti ai quali è stato 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. Ciò 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 agli autori 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 viene modificato in modo da non concedere questa autorizzazione, anche se l'impostazione Gestione autorizzazioni viene attivata per il repository. Sarà necessario concedere l'autorizzazione Modifica criteri concessa in modo esplicito (manualmente o tramite l'API REST) tramite l'ereditarietà delle autorizzazioni di sicurezza o tramite l'appartenenza a un gruppo.
Apri la sicurezza per un repository
È possibile impostare le autorizzazioni del repository Git dalle Impostazioni Progetto>repository.
Aprire il portale Web e scegliere il progetto in cui si desidera aggiungere utenti o gruppi. Per scegliere un altro progetto, vedere Cambiare progetto, repository, team.
Apri Impostazioni progetto>Repository.
Per impostare le autorizzazioni per tutti i repository Git, scegliere Sicurezza.
Ad esempio, qui scegliamo (1) Impostazioni progetto, (2) Repository e quindi (3) Sicurezza.
In caso contrario, per impostare le autorizzazioni per un repository specifico, scegliere (1) il repository e quindi scegliere (2) 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 scegliere il progetto in cui si desidera aggiungere utenti o gruppi. Per scegliere un altro progetto, vedere Cambiare progetto, repository, team.
Per impostare le autorizzazioni per tutti i repository Git per un progetto, scegliere Repository Git e quindi scegliere il gruppo di sicurezza le cui autorizzazioni si desidera gestire.
Ad esempio, qui si sceglie (1) Impostazioni progetto, (2) Repository, (3) repository Git, (4) il gruppo Collaboratori e quindi (5) 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 delle 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 sono ricercabili da un campo identity. Il ritardo può essere compreso tra 5 minuti e 7 giorni.
In caso contrario, scegliere un repository specifico e scegliere il gruppo di sicurezza le cui autorizzazioni si desidera gestire.
Nota
Se si aggiunge un utente o un gruppo e non si modificano le autorizzazioni per tale utente o gruppo, dopo l'aggiornamento della pagina delle autorizzazioni, l'utente o il gruppo aggiunto non viene più visualizzato.
Al termine, scegliere Salva modifiche.
Modificare le autorizzazioni per un gruppo di sicurezza
Per impostare le autorizzazioni per un gruppo di sicurezza personalizzato, assicurati di aver definito quel gruppo in precedenza. Vedere Impostare le autorizzazioni a livello di progetto.
Per impostare le autorizzazioni per un gruppo specifico, scegliere il gruppo. Ad esempio, qui si sceglie il gruppo Collaboratori.
Modificare una o più autorizzazioni. Per concedere un'autorizzazione, modificare Non impostato in Consenti. Per limitare le autorizzazioni, modificare Consenti su Nega.
Al termine, allontanarsi dalla pagina. 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 selezionarlo dalle identità visualizzate.
Apportare quindi le modifiche al set di autorizzazioni.
Nota
Potrebbe non essere possibile trovare un utente da una pagina delle 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 sono ricercabili da un campo identity. Il ritardo può essere compreso tra 5 minuti e 7 giorni.
Al termine, allontanarsi dalla pagina. Le modifiche alle autorizzazioni vengono salvate automaticamente per il gruppo selezionato.
Nota
Se si aggiunge un utente o un gruppo e non si modificano le autorizzazioni per tale utente o gruppo, dopo l'aggiornamento della pagina delle autorizzazioni, l'utente o il gruppo aggiunto 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à in una posizione attiva o disattivata.
Per informazioni sull'ereditarietà, vedere Informazioni su autorizzazioni e gruppi, Ereditarietà e gruppi di sicurezza.
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. Ad esempio, quando si ripristina una modifica che ha causato un'interruzione di compilazione o l'applicazione di un hotfix durante la notte. In precedenza, l'autorizzazione esentata dall'imposizione dei criteri ha consentito ai team di gestire gli utenti a cui è stata concessa la possibilità di ignorare i criteri di ramo durante il completamento di una richiesta pull. Tuttavia, quell'autorizzazione ha anche concesso la possibilità di eseguire il push direttamente sul ramo, saltando completamente il processo di richiesta pull.
Per migliorare questa esperienza, abbiamo suddiviso il permesso Esenti dall'applicazione delle politiche per offrire maggiore controllo ai team che forniscono permessi di aggiramento. Le due autorizzazioni seguenti sostituiscono l'autorizzazione precedente:
- Ignora criteri nel completamento delle pull request. Gli utenti con questa autorizzazione potranno usare l'esperienza "Override" per le richieste pull.
- Ignora le politiche durante il push. Gli utenti con questa autorizzazione potranno eseguire il push direttamente sui branch per i quali sono configurati i criteri richiesti.
Concedendo la prima autorizzazione e negando la seconda, un utente può usare l'opzione di bypass quando necessario, ma avrà comunque la protezione dal push accidentale in un ramo con criteri.
Nota
Questa modifica non introduce modifiche al comportamento. Agli utenti a cui in precedenza era stato concesso Consenti per l'esenzione dall'applicazione dei criteri viene ora concesso Consenti per entrambe le nuove autorizzazioni, permettendo loro di poter eseguire l'override del completamento delle PR e di spingere direttamente nei rami che hanno criteri.