Esta versão do GitHub Enterprise será descontinuada em 2022-02-16. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, melhorar a segurança e novos recursos, upgrade to the latest version of GitHub Enterprise. Para ajuda com a atualização, contact GitHub Enterprise support.

Gerenciar uma regra de proteção de branch

Você pode criar uma regra de proteção de branch para aplicar certos fluxos de trabalho para um ou mais branches, como exigir uma revisão de aprovação ou verificações de status de aprovação para todos os pull requests mesclados no branch protegido.

People with admin permissions to a repository can manage branch protection rules.

Branches protegidos estão disponíveis em repositórios públicos com GitHub Free e GitHub Free para organizações e em repositórios públicos e privados com GitHub Pro, GitHub Team, GitHub Enterprise Cloud e GitHub Enterprise Server.

Sobre as regras de proteção do branch

Você pode criar uma regra de proteção de branch em um repositório para um branch específico, todos os branches, ou qualquer branch que corresponde a um padrão de nome que você especificar com a sintaxe fnmatch. Por exemplo, para proteger qualquer branch que contenha a palavra versão, você pode criar uma regra de branch para *versão*.

É possível criar uma regra para todos os branches atuais e futuros no repositório com a sintaxe curinga *. Pelo fato de o GitHub usar o sinalizador File::FNM_PATHNAME para a sintaxe File.fnmatch, o curinga não corresponde aos separadores de diretório (/). Por exemplo, qa/* pode fazer correspondência com todos os branches que começam com qa/ e contêm uma única barra. Você pode incluir várias barras com qa/**/* e você pode estender a string qa com qa**/**/* para tornar a regra mais inclusiva. Para obter mais informações sobre opções de sintaxe para regras de branch, consulte a documentação de fnmatch.

Se um repositório tiver várias regras de branch protegido que afetem os mesmos branches, as regras que incluírem um nome de branch específico terão a prioridade mais alta. Se houver mais de uma regra de branch protegido que faça referência ao mesmo nome de branch específico, a regra de branch criada primeiro terá a prioridade mais alta.

As regras de branch protegido que mencionam um caractere especial, como *, ? ou ], são aplicadas na ordem em que foram criadas, de modo que as regras mais antigas com esses caracteres têm uma prioridade mais alta.

Para criar uma exceção a uma regra de branch existente, você pode criar outra regra de proteção de branch que tenha prioridade superior, como uma regra para um nome de branch específico.

Para obter mais informações sobre cada uma das configurações de proteção de branch disponíveis, consulte "Sobre branches protegidos".

Criar uma regra de proteção de branch

Ao criar uma regra de branch, o branch que você especificar ainda não existe no repositório.

  1. No GitHub Enterprise Server, navegue até a página principal do repositório.

  2. No nome do seu repositório, clique em Configurações. Botão de configurações do repositório

  3. No menu à esquerda, clique em Branches. Submenu de opções do repositório

  4. Ao lado de "Regras de proteção do branch", clique Adicionar regra. Botão de adicionar regra de proteção do branch

  5. Em "Padrão do nome do branch", digite o nome de branch ou padrão que você deseja proteger. Campo regra do branch

  6. Opcionalmente, habilite as revisões obrigatórias de de pull request.

    • Em "Proteger os branches correspondentes", selecione Exigir revisões de pull request antes do merge. Caixa de seleção Pull request review restriction (Restrição de revisão de pull request)

    • Clique no menu suspenso Revisões obrigatórias de aprovação e, em seguida, selecione o número de revisões que deseja exigir no branch. Menu suspenso para selecionar o número de revisões de aprovação obrigatórias

    • Opcionalmente, para ignorar uma revisão de aprovação de pull request quando um commit de modificação de código for enviado por push para o branch, selecione Ignorar aprovações obsoletas de pull request quando novos commits forem enviados por push. Caixa de seleção Dismiss stale pull request approvals when new commits are pushed (Ignorar aprovações de pull requests obsoletas ao fazer push de novos commits)

    • Opcionalmente, para exigir a revisão de um proprietário do código quando o pull request afeta o código que tem um proprietário designado, selecione Exigir revisão de Proprietários do Código. Para obter mais informações, consulte "Sobre proprietários do código". Require review from code owners (Exigir revisão de proprietários de código)

    • Opcionalmente, se o repositório fizer parte de uma organização, selecione Restringir quem pode ignorar as revisões de pull request. Em seguida, procure e selecione as pessoas ou equipes que têm permissão para ignorar as revisões de pull request. Para obter mais informações, consulte " Ignorar uma revisão de pull request". Caixa de seleção Restrict who can dismiss pull request reviews (Restringir quem pode ignorar revisões de pull request)

     1. Opcionalmente, habilite as verificações de status obrigatórias. 
      - Selecione **Require status checks to pass before merging** (Exigir verificações de status para aprovação antes de fazer merge). ![Opção Required status checks (Verificações de status obrigatórias)](/assets/images/help/repository/required-status-checks.png)
    
  7. Opcionalmente, para garantir que os pull requests sejam testados com o código mais recente no branch protegido, selecione Exigir que os branches estejam atualizados antes do merge. Caixa de seleção Status obrigatório rígido ou flexível

  8. Na lista de verificações de status disponíveis, selecione as verificações que você deseja tornar obrigatórias.Lista de verificações de status disponíveis

  9. Opcionalmente, selecione Exigir commits assinados. Opção Require signed commits (Exigir commits assinados)

  10. Opcionalmente, selecione Exigir histórico linear. Opção de histórico linear necessária

  11. Outra opção é selecionar Include administrators (Incluir administradores). Caixa de seleção Include administrators (Incluir administradores)

  12. Opcionalmente, habilitar as restrições de branches.

    • Selecione Restringir quem pode fazer push para os branches correspondentes. Caixa de seleção Branch restriction (Restrição de branch)

    • Procurar e selecionar pessoas, equipes ou aplicativos que tenham permissão para fazer push para o branch protegido. Pesquisa de restrição de branch

  13. Opcionalmente, em "Regras aplicadas a todos incluindo administradores", selecione Permitir pushes forçados. Permitir opção push forçado

  14. Opcionalmente, selecione Permitir exclusões. Permitir a opção de exclusão de branch

  15. Clique em Criar.

Editar uma regra de proteção de branch

  1. No GitHub Enterprise Server, navegue até a página principal do repositório.
  1. No nome do seu repositório, clique em Configurações. Botão de configurações do repositório
  1. No menu à esquerda, clique em Branches. Submenu de opções do repositório

  2. À direita da regra de proteção de branch que você deseja editar, clique em Editar. Botão editar

  3. Faça as alterações desejadas na regra de proteção do branch.

  4. Clique em Save changes (Salvar alterações). Botão Edit message (Editar mensagem)

Excluir as regras de proteção do branch

  1. No GitHub Enterprise Server, navegue até a página principal do repositório.
  1. No nome do seu repositório, clique em Configurações. Botão de configurações do repositório
  1. No menu à esquerda, clique em Branches. Submenu de opções do repositório

  2. À direita da regra de proteção do branch que você deseja excluir, clique em Excluir. Botão excluir

Esse documento ajudou você?

Política de Privacidade

Ajude-nos a tornar esses documentos ótimos!

Todos os documentos do GitHub são de código aberto. Você percebeu que algo que está errado ou não está claro? Envie um pull request.

Faça uma contribuição

Ou, aprenda como contribuir.