Este tópico descreve as configurações de branch para um repositório de código.
Informações básicas
As configurações de branch dividem-se em duas partes:
-
Configurações da branch padrão
A branch padrão serve como base para clonagem, criação de novas branches, abertura de merge requests e navegação pelo código. Também é possível protegê-la contra exclusões acidentais. O gerente do repositório de código pode alterar a branch padrão para adequá-la às práticas de desenvolvimento da equipe.
-
Configurações de branch protegida
Uma branch protegida restringe exclusões e force pushes. O gerente do repositório de código pode definir regras para proteger branches importantes, evitar exclusões acidentais e force pushes, além de garantir a segurança das branches essenciais e a rastreabilidade de seus commits.
Acessar as configurações de branch
Como gerente do repositório de código, acesse o repositório e clique em na barra de menu superior.

Crie uma regra de branch protegida
Siga estas etapas para criar uma regra de branch protegida:

Etapa 1: Selecione uma branch
Especifique uma branch de uma das duas formas abaixo:
Método 1: Insira o nome completo de uma branch específica.
-
Método 2: Utilize um padrão com curingas (apenas
?e*são suportados). Se o padrão corresponder a várias branches, todas as correspondentes serão exibidas.-
Qual regra prevalece quando uma branch protegida corresponde a múltiplas regras?
Precedência: Se uma branch no repositório de código corresponder a várias regras de branch protegida, a regra que visa um nome de branch específico terá a maior prioridade. Quando uma branch corresponder a múltiplas regras com curingas, a regra criada primeiro terá precedência.
-
Por exemplo, considere um repositório de código com as branches
master-1,master-2emaster-prod-1. As regras de proteção foram criadas na seguinte ordem:master-*,master-1emaster-prod-*. A tabela a seguir mostra como as regras são aplicadas.Nome da branch
Regras correspondentes
Regra efetiva
master-1
master-*, master-1
master-1
master-2
master-*
master-*
master-prod-1
master-, master-prod-
master-*
-
Etapa 2: Configure regras de push
Defina quais funções e membros têm permissão para fazer push diretamente nesta branch protegida.
Funções permitidas: Por padrão, as funções de gerente e desenvolvedor podem fazer push. Para impedir que uma função faça push, desmarque-a. Se você selecionar
None, ninguém poderá fazer push para a branch.Membros permitidos: Conceda acesso de push a membros específicos do repositório de código. Os membros selecionados devem ter permissões de gravação no repositório.
Etapa 3: Configure regras de merge
Especifique quais funções e membros podem realizar o merge de um merge request.
Funções permitidas: Por padrão, as funções de gerente e desenvolvedor podem realizar merges. Desmarque uma função para bloquear sua capacidade de merge.
Membros permitidos: Conceda permissões de merge a membros específicos do repositório de código. Os membros selecionados precisam ter permissões de gravação no repositório.
As permissões de funções e membros individuais são combinadas. Por exemplo, se apenas a função de gerente tiver permissão de push, mas você permitir especificamente um desenvolvedor chamado Usuário A, tanto os gerentes quanto o Usuário A poderão fazer push para a branch protegida, mesmo que o Usuário A não seja gerente.
Etapa 4: Configure uma regra de aprovação
Configure regras de aprovação manual

Defina as seguintes condições para uma revisão de código:
Permitir que o criador aprove: Sim / Não.
Exigir que todos os comentários da revisão de código sejam resolvidos antes do merge.
Dois modos de aprovação estão disponíveis:
-
Modo geral:
Número mínimo de aprovadores necessários: 1.
Funções autorizadas a aprovar: gerente + desenvolvedor.
Revisores padrão: esta seção fica oculta se nenhum revisor for especificado. Adicione até 20 revisores.
-
Modo CodeOwner:
Para mais informações sobre o CodeOwner, consulte Mecanismo CodeOwner.
Configure regras de verificação automatizada
-
Verificação de código
Merge requests só podem ser bloqueados por esta verificação se uma tarefa de verificação de código estiver ativada. Para detalhes de configuração, consulte Usar o serviço de detecção de código.

Após ativar a tarefa de verificação de código, exija-a como critério de merge.

-
Verificação de pipeline
Em uma branch protegida, integre um pipeline do Flow para adicionar critérios de merge aos merge requests.

Caso o repositório de código não esteja associado a um pipeline, acesse o Alibaba Cloud DevOps Flow para criar ou associar um pipeline. Consulte Como associar um pipeline do Flow.
ImportantePara acionar automaticamente a verificação do pipeline a cada commit de código, selecione o evento de gatilho code commit ao criar o pipeline. Caso contrário, será necessário acionar o pipeline manualmente para obter o resultado da verificação, pois esse resultado é obrigatório para a aprovação do merge request.

Depois de associar um pipeline, selecione-o aqui para usá-lo como critério de merge.

O pipeline selecionado torna-se uma verificação obrigatória para qualquer merge request direcionado a esta branch protegida. O pipeline deve ser aprovado antes que o merge request possa ser mesclado.
ImportanteCertifique-se de que o pipeline designado como critério de merge tenha sido executado com sucesso pelo menos uma vez.