Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022
Gere quem pode aceder aos teus repositórios Git e que ações podem realizar. Defina permissões ao nível de Todos os Repositórios para as aplicar a todos os repositórios Git de um projeto, ou defina permissões para um repositório individual. Repositórios individuais herdam permissões da entrada Git ao nível do projeto.
Nota
As ramificações herdam um subconjunto de permissões de atribuições feitas no nível do repositório. Para permissões e políticas de ramo, consulte Definir permissões de ramo e Melhorar a qualidade do código com políticas de ramo.
Para um guia de segurança abrangente sobre permissões de repositórios, políticas de branch, assinatura de commits e cenários reais de implementação, consulte Repositórios Seguros e pull requests.
Para orientações sobre quem deve fornecer níveis de permissões mais elevados, consulte Gerir acesso usando permissões.
Pré-requisitos
| Categoria | Requerimentos |
|---|---|
| Acesso ao projeto | Adesão a um projeto Azure DevOps. |
| Permissões | Gerir permissões para a entrada dos repositórios Git ao nível do projeto para gerir todos os repositórios do projeto, ou Gerir permissões para um repositório individual gerir esse repositório. Os membros do grupo Project Administrators têm esta permissão por defeito. Para obter mais informações, consulte Referência de permissões e grupos. |
| Services | Repositórios do Azure ativado. |
Rever permissões padrão do repositório
Por padrão, os membros do grupo de Colaboradores do projeto têm permissões para contribuir com um repositório. Este nível de permissão inclui a capacidade de criar ramos, criar etiquetas e gerir notas. Para obter uma descrição de cada grupo de segurança e nível de permissão, consulte Permissões e referência de grupo.
Permissão
Leitores
Contribuidores
Administradores de compilações
Administradores de Projeto
Ler (clonar, buscar e explorar o conteúdo de um repositório); também pode criar, comentar, votar e contribuir para receber solicitações
✔️
✔️
✔️
✔️
Contribuir, Criar ramos, Criar etiqueta e Gerir notas
✔️
✔️
✔️
Criar repositório, Excluir repositório e Renomear repositório
✔️
Editar políticas, Gerenciar permissões, Remover bloqueios de outras pessoas
✔️
Ignorar políticas ao concluir pull requests, Ignorar políticas ao efetuar o push, Force push (reescrever histórico, eliminar ramificações e tags)
(não definido para nenhum grupo de segurança)
A partir do Azure DevOps sprint 224, os criadores de branch não recebem automaticamente a permissão de Editar políticas. Esta permissão não é concedida mesmo que a definição de gestão de permissões esteja ativada para o repositório. Políticas de Edição de Concessão explicitamente através de herança, pertença a um grupo ou uma cessão direta.
No Azure DevOps Server 2022.1 e posteriores, os criadores de branch não obtêm automaticamente a permissão de Editar políticas. Esta permissão não é concedida mesmo que a definição de gestão de permissões esteja ativada para o repositório. Políticas de Edição de Concessão explicitamente através de herança, pertença a um grupo ou uma cessão direta. Para mais informações, consulte as notas de versão do Azure DevOps Server 2022 Update 1.
Compreendo que as autorizações declaram
Antes de alterar uma permissão, reveja como o Azure DevOps avalia os estados de permissões:
- Não definir não concede nem nega a permissão. Permissões atribuídas através de outro grupo ou herdadas de um âmbito parental ainda podem aplicar-se.
- Permitir concede a permissão, a menos que uma recusa mais específica ou aplicável a sobreponha.
- Recusa geralmente sobrepõe-se a Permitir, incluindo permissões herdadas ou concedidas através de outro grupo. Quando nega uma permissão a um grupo, a recusa afeta todos os membros desse grupo.
Revise a pertença ao grupo e as permissões herdadas antes de atribuir o Denegar. Para mais informações, consulte Sobre permissões e grupos.
Segurança de repositórios abertos
Defina permissões do repositório Git a partir das definições> do ProjectRepositories.
Abra o portal web e selecione o projeto onde quer adicionar utilizadores ou grupos. Para selecionar outro projeto, consulte Alternar projeto, repositório, equipa.
Selecione Configurações do projeto>Repositórios.
Para definir permissões para cada repositório Git no projeto, selecione Segurança de Todos os Repositórios>.
Para definir permissões para um repositório específico, selecione o repositório e depois selecione Segurança.
Defina permissões do repositório Git a partir das definições> do ProjectRepositories.
Abre o portal web e seleciona o projeto onde queres gerir permissões. Para selecionar outro projeto, consulte Alternar projeto, repositório, equipa.
Selecione Configurações do projeto>Repositórios.
Para definir permissões para cada repositório Git no projeto, selecione repositórios Git e depois selecione o utilizador ou grupo de segurança cujas permissões pretende gerir.
Para ver a imagem completa, clique na imagem para expandir. Escolha o
para fechar.
Caso contrário, selecione um repositório específico e depois selecione o utilizador ou grupo de segurança cujas permissões pretende gerir.
Muda as permissões e depois seleciona Guardar alterações.
Confirme que cada permissão alterada mantém o seu novo estado.
Alterar permissões para um grupo
Para definir permissões para um grupo de segurança personalizado, defina primeiro o grupo. Para obter mais informações, consulte Alterar permissões ao nível do projeto.
Selecione o grupo para definir permissões. Por exemplo, selecione Colaboradores.
Altere uma ou mais permissões. Para conceder uma permissão, selecione Permitir. Para remover uma atribuição explícita e usar permissões herdadas ou de grupo, selecione Não definido. Selecione Negar apenas quando precisar de anular um Permitir aplicável.
As alterações de permissões são guardadas automaticamente. Confirme que cada permissão alterada mostra o estado pretendido.
Alterar permissões para um usuário
Introduza o nome do utilizador no filtro de pesquisa e selecione entre as identidades que parecem definir permissões para um utilizador específico.
Altere uma ou mais permissões para o utilizador selecionado.
Nota
Pode não conseguir encontrar um utilizador numa página de permissões ou num campo de identidade se o utilizador não foi adicionado ao projeto, seja ao adicioná-lo a um grupo de segurança ou a uma equipa de projeto. Além disso, quando um utilizador é adicionado ao Microsoft Entra ID ou Active Directory, pode haver um atraso entre o momento em que é adicionado ao projeto e o momento em que é pesquisável a partir de um campo de identidade. O atraso pode ser entre 5 minutos a 7 dias.
As alterações de permissões são automaticamente guardadas para o utilizador selecionado. Confirme que cada permissão alterada mostra o estado pretendido.
Podes adicionar um utilizador ou grupo e não alterar quaisquer permissões para esse utilizador ou grupo. Após a atualização da página de permissões, o utilizador ou grupo deixa de aparecer.
Configurar a herança para um repositório
Antes de alterar a herança, regista a definição atual e revê as permissões explícitas e herdadas do repositório. Quando desativa a herança, as permissões da entrada do repositório Git ao nível do projeto deixam de ser transferidas para o repositório. Verifique se as tarefas restantes fornecem o acesso pretendido antes de continuar.
Para ativar ou desativar a herança para um repositório específico, selecione o repositório e depois defina Herança para Ligado ou Desligado.
Depois de alterar a herança, verifique as atribuições de permissões do repositório com um utilizador representativo afetado. Se o resultado estiver incorreto, restaure a configuração anterior e os estados de permissões. Para saber mais sobre herança, veja Sobre permissões e grupos.
Configurar permissões de bypass de políticas
Há muitos cenários em que é ocasionalmente necessário ignorar uma política de ramificação. Alguns exemplos são quando revertes uma alteração que causou uma quebra de build ou aplicas um hotfix no meio da noite.
Anteriormente, a permissão de Isenção da aplicação de políticas ajudava as equipas a gerir quais os utilizadores que tinham a capacidade de ignorar as políticas de ramificação quando concluíam um pull request. No entanto, essa permissão também concedia aos utilizadores a capacidade de empurrar diretamente para a agência e contornar completamente o processo de PR.
As duas permissões seguintes substituem o Isento da aplicação da política e proporcionam um controlo mais detalhado:
- Políticas de bypass ao concluir pull requests: Os utilizadores com esta permissão podem usar a experiência de override para pull requests.
- Contornar políticas ao fazer push: Os utilizadores com esta permissão podem enviar diretamente para ramificações onde as políticas requeridas estão configuradas.
Para permitir que um utilizador contorne políticas apenas ao completar pull requests, defina as políticas de Bypass ao concluir pull requests como Permitir. Deixar políticas de Bypass ao empurrar como Não definido se o utilizador não receber Permitir através de outra atribuição. Defina para Negar apenas quando precisar de sobrescrever um Permitir aplicável.
Nota
Utilizadores que anteriormente tinham Isento da aplicação de políticas definido para Permitir receberam Permitir para ambas as permissões de substituição. Revise estas atribuições e defina políticas de Bypass ao empurrar para Não definido quando os utilizadores não precisam de enviar diretamente para branches protegidas e nenhuma outra atribuição concede essa permissão.
Alterações de permissões para resolução de problemas
Use as seguintes orientações quando uma alteração de permissão não tiver o resultado esperado:
| Issue | Resolução |
|---|---|
| Não podes mudar uma permissão | Verifique se tem permissões de Gestão na entrada dos repositórios Git ao nível do projeto ou no repositório selecionado. |
| Um utilizador ou grupo não aparece na pesquisa | Adicione a identidade ao projeto através de uma equipa ou grupo de segurança. As alterações de identidade podem demorar tempo a aparecer nas pesquisas. |
| Uma Permissão não concede acesso | Verifique as pertenças de grupo dos utilizadores e os escopos mais específicos para um Negação aplicável. |
| Uma permissão afeta os repositórios errados | Confirme se alterou Todos os Repositórios ou um repositório individual. |
| Uma permissão retorna depois de selecionar Não definir | Verifique se a autorização é herdada ou concedida através de outro grupo. |
| Desativar a herança remove o acesso | Restaure a configuração de herança anterior ou as atribuições explícitas de permissões que registou antes da alteração. |
Depois de resolver o problema, peça a um utilizador representativo afetado para verificar a ação pretendida do repositório.
Sugestão
Pode usar IA para ajudar com tarefas do Azure DevOps. Consulte Ative assistência de IA com Azure DevOps MCP Server para começar.