Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Serviços do Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Gerencie quem pode acessar seus repositórios Git e quais ações eles podem executar. Defina permissões no nível Todos os Repositórios para aplicá-las a cada repositório Git em um projeto ou defina permissões para um repositório individual. Repositórios individuais herdam permissões da entrada de repositórios Git no nível do projeto.
Observação
As ramificações herdam um subconjunto de permissões das atribuições realizadas no nível do repositório. Em relação às permissões e políticas de branch, consulte Definir permissões de branch e Melhorar a qualidade do código com políticas de branch.
Para obter um guia de segurança abrangente sobre permissões de repositório, políticas de ramificação, assinatura de commit e cenários reais de implementação, consulte Repositórios seguros e pull requests.
Para obter diretrizes sobre quem fornecer níveis de permissão maiores, consulte Gerenciar o acesso usando permissões.
Pré-requisitos
| Categoria | Requirements |
|---|---|
| Acesso ao Projeto | Associação a um projeto de Azure DevOps. |
| Permissões | Gerencie permissões para a entrada de repositórios Git no nível do projeto para gerenciar cada repositório no projeto ou gerenciar permissões para um repositório individual gerenciar esse repositório. Os membros do grupo administradores do Project têm essa permissão por padrão. Para saber mais, consulte Referência de permissões e grupos. |
| Services | Azure Repos habilitado. |
Examinar permissões de repositório padrão
Por padrão, os membros do grupo Colaboradores do projeto têm permissões para contribuir com um repositório. Esse nível de permissão inclui a capacidade de criar branches, criar marcas e gerenciar anotações. 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
Colaboradores
Criar Administradores
Administradores do Projeto
Ler (clonar, buscar e explorar o conteúdo de um repositório); também pode criar, comentar, votar e Contribuir em solicitações de pull
✔️
✔️
✔️
✔️
Contribuir, criar branch, criar marca e gerenciar anotações
✔️
✔️
✔️
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 solicitações de pull, Ignorar políticas ao enviar por push, Forçar push (histórico de reescrita, excluir branches e marcas)
(não definido para nenhum grupo de segurança)
Começando com Azure DevOps sprint 224, os criadores de branch não obtêm automaticamente a permissão Editar políticas. Essa permissão não será concedida mesmo se a configuração de gerenciamento de permissões estiver ativada para o repositório. Conceda políticas de Edição explicitamente por meio de herança, associação de grupo ou uma atribuição direta.
No Azure DevOps Server 2022.1 e posterior, os criadores de branch não recebem automaticamente a permissão Editar políticas. Essa permissão não será concedida mesmo se a configuração de gerenciamento de permissões estiver ativada para o repositório. Conceda políticas de Edição explicitamente por meio de herança, associação de grupo ou uma atribuição direta. Para obter mais informações, consulte Azure DevOps Server notas de versão da Atualização 1 de 2022.
Entender os estados de permissão
Antes de alterar uma permissão, examine como Azure DevOps avalia os estados de permissão:
- Não definido não concede ou nega a permissão. As permissões atribuídas por outro grupo ou herdadas de um escopo pai ainda podem ser aplicadas.
- Permitir concede a permissão, a menos que uma Negação mais específica ou aplicável a substitua.
- Negar geralmente substitui Permitir, incluindo permissões herdadas ou concedidas por meio de outro grupo. Quando você nega uma permissão para um grupo, a negação afeta todos os membros desse grupo.
Examine a associação de grupo e as permissões herdadas antes de atribuir Deny. Para obter mais informações, consulte Sobre permissões e grupos.
Abrir a segurança do repositório
Defina as permissões do repositório Git deProject repositórios de configurações>.
Abra o portal da Web e selecione o projeto no qual você deseja adicionar usuários ou grupos. Para selecionar outro projeto, consulte Switch project, repository, team.
Selecione Configurações do projeto>Repositórios.
Para definir permissões para cada repositório Git no projeto, selecione Todos os Repositórios>de Segurança.
Para definir permissões para um repositório específico, selecione o repositório e selecione Segurança.
Defina as permissões do repositório Git deProject repositórios de configurações>.
Abra o portal da Web e selecione o projeto no qual você deseja gerenciar permissões. Para selecionar outro projeto, consulte Switch project, repository, team.
Selecione Configurações do projeto>Repositórios.
Para definir permissões para cada repositório Git no projeto, selecione repositórios Git e selecione o usuário ou grupo de segurança cujas permissões você deseja gerenciar.
Para ver a imagem completa, clique na imagem para expandi-la. Escolha o
para fechar.Caso contrário, selecione um repositório específico e selecione o usuário ou grupo de segurança cujas permissões você deseja gerenciar.
Altere as permissões e selecione Salvar alterações.
Confirme se cada permissão alterada mantém seu novo estado.
Alterar permissões para um grupo
Para definir permissões para um grupo de segurança personalizado, primeiro defina o grupo. Para obter mais informações, consulte Alterar permissões de nível de 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 definir. Selecione Negar somente quando precisar substituir um Allow aplicável.
As alterações de permissão são salvas automaticamente. Confirme se cada permissão alterada exibe o estado pretendido.
Alterar permissões para um usuário
Insira o nome do usuário no filtro de pesquisa e selecione entre as identidades que parecem definir permissões para um usuário específico.
Altere uma ou mais permissões para o usuário selecionado.
Observação
Talvez você não consiga encontrar um usuário de uma página de permissões ou de um campo de identidade se o usuário não tiver sido adicionado ao projeto adicionando-o a um grupo de segurança ou a uma equipe de projeto. Além disso, quando um usuário é adicionado à ID do Microsoft Entra ou ao Active Directory, pode haver um atraso entre o tempo em que ele é adicionado ao projeto e quando ele é pesquisável em um campo de identidade. O atraso pode se estender de 5 minutos a 7 dias.
As alterações de permissão são salvas automaticamente para o usuário selecionado. Confirme se cada permissão alterada exibe o estado pretendido.
Você pode adicionar um usuário ou grupo e não alterar nenhuma permissão para esse usuário ou grupo. Depois que a página de permissões for atualizada, o usuário ou grupo não será mais exibido.
Configurar a herança para um repositório
Antes de alterar a herança, registre a configuração atual e examine as permissões explícitas e herdadas do repositório. Quando você desativa a herança, as permissões da entrada de repositórios Git no nível do projeto não fluem mais para o repositório. Verifique se as atribuições restantes fornecem o acesso pretendido antes de continuar.
Para habilitar ou desabilitar a herança de um repositório específico, selecione o repositório e defina Herança como Ativada ou Desativada.
Depois de alterar a herança, verifique as atribuições de permissão do repositório com um usuário afetado representativo. Se o resultado estiver incorreto, restaure os estados de configuração e permissão anteriores. Para saber mais sobre herança, consulte Sobre permissões e grupos.
Configurar permissões de bypass de política
Há muitos cenários em que você ocasionalmente necessitará ignorar alguma política de branch. Alguns exemplos são quando você reverte uma alteração que causou uma quebra de build ou aplica um hotfix no meio da noite.
Anteriormente, a permissão Isento de imposição de política ajudava as equipes a gerenciar quais usuários tinham a capacidade de ignorar as políticas de ramificação quando finalizavam um pull request. No entanto, essa permissão também concedia aos usuários a capacidade de enviar alterações diretamente para a branch e ignorar completamente o processo de PR.
As duas permissões a seguir substituem Isentas da imposição de políticas e fornecem um controle mais granular:
- Ignorar políticas ao concluir pull requests: usuários com essa permissão podem usar a experiência de substituição para pull requests.
- Ignorar políticas ao enviar alterações: usuários com essa permissão podem enviar alterações diretamente para branches com as políticas necessárias configuradas.
Para permitir que um usuário ignore as políticas somente ao concluir solicitações de pull, defina políticas de bypass ao concluir solicitações de pull para Permitir. Deixe as políticas de bypass ao enviar por push como Não definido se o usuário não receber Permitir por meio de outra atribuição. Defina-o como Negar somente quando você precisar substituir um Allow aplicável.
Observação
Os usuários que anteriormente tinham Isenção da imposição de política definida como Permitir receberam Permissão para ambas as permissões de substituição. Examine essas atribuições e defina políticas de bypass ao enviar por push para Não definir quando os usuários não precisam enviar por push diretamente para branches protegidos e nenhuma outra atribuição concede a permissão.
Solucionar problemas de alterações de permissão
Use as seguintes diretrizes quando uma alteração de permissão não tiver o resultado esperado:
| Issue | Resolução |
|---|---|
| Você não pode alterar uma permissão | Verifique se você tem permissões Gerenciar na entrada de repositórios Git no nível do projeto ou no repositório selecionado. |
| Um usuário ou grupo não aparece na pesquisa | Adicione a identidade ao projeto por meio de uma equipe ou grupo de segurança. As alterações de identidade podem levar tempo para aparecer na pesquisa. |
| Uma permissão não concede acesso | Verifique as associações de grupo do usuário e escopos mais específicos para uma Negação aplicável. |
| Uma permissão afeta os repositórios errados | Confirme se você alterou todos os repositórios ou um repositório individual. |
| Uma permissão retorna depois que você seleciona Não definir | Verifique se a permissão é herdada ou concedida por meio de outro grupo. |
| Desabilitar a herança remove o acesso | Restaure a configuração de herança anterior ou as atribuições de permissão explícitas que você registrou antes da alteração. |
Depois de resolver o problema, faça com que um usuário afetado representativo verifique a ação de repositório pretendida.
Dica
Você pode usar a IA para ajudar nas tarefas do Azure DevOps. Consulte Ativar assistência de IA com o servidor MCP do Azure DevOps para começar.