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 2022 | Azure DevOps Server 2020
Gerencie o acesso aos repositórios para bloquear quem pode contribuir com seu código-fonte e gerenciar outros recursos. Você pode definir permissões em todos os repositórios Git fazendo alterações na entrada de nível superior dos repositórios Git. Os repositórios individuais herdam permissões da entrada de nível superior Repositórios Git.
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 obter orientação sobre quem fornecer maiores níveis de permissão, consulte Gerenciar acesso usando permissões.
Pré-requisitos
| Categoria | Requerimentos |
|---|---|
| Acesso ao projeto | Membro de um projeto . |
| Permissões | - Ver código em projetos privados: Acesso pelo menos Básico. - Clone ou contribua para o código em projetos privados: Membro do grupo de segurança Contributors ou permissões correspondentes no projeto. - Definir permissões de ramo ou repositório: Gerir permissões para o ramo ou repositório. - Alterar ramificação padrão: Editar políticas e permissões para o repositório. - Importar um repositório: Membro do grupo de segurança Administradores de Projeto ou com permissão de Criar repositório ao nível do projeto Git definida como Permitir. Para obter mais informações, consulte Definir permissões do repositório Git. |
| Serviços | Repos ativado. |
| Ferramentas | Opcional. Utilize os comandos az repos: Azure DevOps CLI. |
Nota
Em projetos públicos, os usuários com acesso Partes Interessadas têm acesso total aos repositórios do Azure, incluindo visualização, clonagem e contribuição para o código.
| Categoria | Requerimentos |
|---|---|
| Acesso ao projeto | Membro de um projeto . |
| Permissões | - Visualização de código: Pelo menos acesso básico. - Clone ou contribua para o código: Membro do grupo de segurança Contributors ou com permissões correspondentes no projeto. |
| Serviços | Repos ativado. |
Para contribuir com o código-fonte, tenha nível de acesso Básico ou superior. Os utilizadores com acesso de Stakeholder para projetos privados não têm acesso ao código-fonte. Os usuários que receberam acesso de Partes Interessadas para projetos públicos têm o mesmo acesso que os Colaboradores e aqueles que recebem acesso Básico . Para obter mais informações, consulte Sobre níveis de acesso.
Para contribuir com o código-fonte, tenha nível de acesso Básico ou superior. Os usuários com acesso às partes interessadas não têm acesso ao código-fonte. Para obter mais informações, consulte Sobre níveis de acesso.
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. Isso inclui a capacidade de criar ramificações, criar tags e gerenciar 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 Build
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
✔️
✔️
✔️
✔️
Contribua, crie ramificações, crie tags e gerencie 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 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 (Azure DevOps Services e Azure DevOps Server 2022.1 e superior), a permissão Editar políticas não é mais concedida automaticamente aos criadores de filiais. Anteriormente, quando criava um novo ramo, era-lhe concedida a permissão para editar políticas nesse ramo. Com esta atualização, estamos a alterar o comportamento predefinido para não conceder esta permissão, mesmo que a definição Gestão de permissões esteja ativada para o repositório. Precisará da permissão Editar políticas concedida explicitamente (manualmente ou através da API REST) através da herança de permissões de segurança ou através de uma associação a um grupo.
Segurança aberta para um repositório
As permissões do repositório Git são definidas em Configurações do Projeto> Repositórios.
Abra o portal Web e escolha o projeto a que pretende adicionar utilizadores ou grupos. Para escolher outro projeto, consulte Mudar projeto, repositório, equipa.
Abra Configurações do projeto> Repositórios.
Para definir as permissões para todos os repositórios Git, escolha Segurança.
Por exemplo, aqui escolhemos (1) Configurações do projeto, (2) Repositórios e, em seguida, (3) Segurança.
Caso contrário, para definir permissões para um repositório específico, escolha (1) o repositório e, em seguida, escolha (2) Segurança.
Definir permissões para um repositório
Você pode gerenciar o acesso a um repositório definindo o estado de permissão como Permitir ou Negar para um único usuário ou um grupo de segurança.
Abra o portal Web e escolha o projeto a que pretende adicionar utilizadores ou grupos. Para escolher outro projeto, consulte Mudar projeto, repositório, equipa.
Para definir as permissões para todos os repositórios Git para um projeto, escolha Repositórios Git e, em seguida, escolha o grupo de segurança cujas permissões você deseja gerenciar.
Por exemplo, aqui escolhemos (1) Configurações do projeto, (2) Repositórios, (3) repositórios Git, (4) o grupo de Colaboradores e, em seguida, (5) a permissão para Criar repositório.
Para ver a imagem completa, clique na imagem para expandir. Escolha o
para fechar.
Nota
Talvez você não consiga encontrar um usuário em uma página de permissões ou campo de identidade se o usuário não tiver sido adicionado ao projeto, seja adicionando-o a um grupo de segurança ou a uma equipe de projeto. Além disso, quando um usuário é adicionado ao Microsoft Entra ID ou ao Ative Directory, pode haver um atraso entre o momento em que ele é adicionado ao projeto e quando ele pode ser pesquisado a partir de um campo de identidade. O atraso pode ser entre 5 minutos a 7 dias.
Caso contrário, escolha um repositório específico e escolha o grupo de segurança cujas permissões você deseja gerenciar.
Nota
Se você adicionar um usuário ou grupo e não alterar nenhuma permissão para esse usuário ou grupo, após a atualização da página de permissões, o usuário ou grupo adicionado não aparecerá mais.
Quando terminar, escolha Salvar alterações.
Alterar permissões para um grupo de segurança
Para definir permissões para um grupo de segurança personalizado, tenha definido esse grupo anteriormente. Consulte Definir permissões no nível do projeto.
Para definir permissões para um grupo específico, escolha o grupo. Por exemplo, aqui escolhemos o grupo de Colaboradores.
Altere uma ou mais permissões. Para conceder permissões, altere Não definido para Permitir. Para restringir permissões, altere Permitir para Negar.
Quando terminar, navegue para fora da página. As alterações de permissão são salvas automaticamente para o grupo selecionado.
Definir permissões para um usuário específico
Para definir permissões para um usuário específico, insira o nome do usuário no filtro de pesquisa e selecione entre as identidades exibidas.
Em seguida, faça as alterações no conjunto de permissões.
Nota
Talvez você não consiga encontrar um usuário em uma página de permissões ou campo de identidade se o usuário não tiver sido adicionado ao projeto, seja adicionando-o a um grupo de segurança ou a uma equipe de projeto. Além disso, quando um usuário é adicionado ao Microsoft Entra ID ou ao Ative Directory, pode haver um atraso entre o momento em que ele é adicionado ao projeto e quando ele pode ser pesquisado a partir de um campo de identidade. O atraso pode ser entre 5 minutos a 7 dias.
Quando terminar, navegue para fora da página. As alterações de permissão são salvas automaticamente para o grupo selecionado.
Nota
Se você adicionar um usuário ou grupo e não alterar nenhuma permissão para esse usuário ou grupo, após a atualização da página de permissões, o usuário ou grupo adicionado não aparecerá mais.
Ativar ou desativar a herança para um repositório específico
Para habilitar ou desabilitar a herança para um repositório específico, selecione o repositório e mova o controle deslizante Herança para uma posição ativada ou desativada.
Para saber mais sobre herança, consulte Sobre permissões e grupos, herança e grupos de segurança.
Isento da aplicação de políticas e contornar permissões de política
Há muitos cenários em que é ocasionalmente necessário ignorar uma política de ramificação. Por exemplo, ao reverter uma alteração que causou uma falha de compilação ou aplicar um hotfix no meio da noite. Anteriormente, a permissão Isentar da imposição de políticas ajudava as equipas a gerir quais utilizadores recebiam a capacidade de ignorar as políticas de branches ao concluir um pull request. No entanto, essa permissão também concedeu a capacidade de fazer push diretamente para o ramo, ignorando totalmente o processo de PR.
Para melhorar essa experiência, dividimos a permissão Isentar da aplicação de políticas para oferecer mais controle às equipes que estão concedendo permissões de desvio. As duas permissões a seguir substituem a permissão anterior:
- Ignore as políticas ao concluir solicitações pull. Os utilizadores com esta permissão poderão usar a funcionalidade "Substituir" para os pedidos pull.
- Ignorar políticas ao efetuar push. Os utilizadores com esta permissão poderão fazer push diretamente para ramos que têm as políticas necessárias configuradas.
Ao conceder a primeira permissão e negar a segunda, um usuário pode usar a opção de bypass quando necessário, mas ainda terá a proteção contra empurrar acidentalmente para uma ramificação com políticas.
Nota
Esta alteração não introduz quaisquer alterações de comportamento. Os utilizadores que anteriormente receberam Permissão para Isenção da Aplicação de Políticas agora recebem Permitir para ambas as novas permissões, permitindo-lhes assim substituir a conclusão em PRs e enviar diretamente para ramos com políticas.