Skip to main content
Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.

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. Para obter mais informações, consulte os "produtos do GitHub".

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 branches 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.com, 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. In the "Code and automation" section of the sidebar, click Branches.

  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 os pull requests necessários.

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

    • Opcionalmente, para exigir aprovações antes que um pull request possa ser mesclado, selecione Exigir aprovações, clique no menu suspenso Número necessário de aprovações antes do merge e, em seguida, selecione o número de aprovações 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, para permitir que os atores específicos façam push de código para o branch sem criar pull requests, quando necessário, selecione Permitir que os atores especificados ignorem os pull requests necessários. Em seguida, procure e selecione os atores que devem ter permissão para ignorar a criação de um pull request. Permitir os atores específicos que podem ignorar a caixa de seleção de exigências do pull request

    • Opcionalmente, se o repositório fizer parte de uma organização, selecione Restringir quem pode ignorar as revisões de pull request. Em seguida, pesquise e selecione os atores que têm permissão para ignorar as revisões do pull request. Para obter mais informações, consulte "Ignorar uma revisão de pull request". Restringir quem pode ignorar a caixa de seleção de revisões de pull request

  7. Opcionalmente, habilite as verificações de status obrigatórias. Para obter mais informações, consulte "Sobre verificações de status".

    • 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)
    • 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
    • Pesquise verificações de status, selecionando as verificações que você deseja exigir. Interface de pesquisa para verificações de status disponíveis, com lista de verificações necessárias
  8. Opcionalmente, selecione Exige resolução de conversas antes de fazer merge. Exigir resolução de conversas antes de fazer o merge

  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. Opcionalmente, para fazer merge de pull requests usando uma fila de merge, selecione Exigir fila de merge. For information about merge queue, see "Managing a merge queue." Opção de exigir fila de merge

    Dica: O recurso de merge da fila de pull request está atualmente em versão beta pública limitada e sujeito a alterações. Organizations owners can request early access to the beta by joining the waitlist.

  12. Opcionalmente, para escolher em quais ambientes as alterações devem ser implantadas com sucesso antes de fazer merge, selecione Exigir implantações para ser bem-sucedidas antes do merge e, em seguida, selecione os ambientes. Exigir uma opção de implantação bem-sucedida

  13. Opcionalmente, selecione Aplicar as regras acima aos administradores. Aplicar as regras acima à caixa de seleção dos administradores

  14. Opcionalmente, se o repositório pertencer a uma organização que usa GitHub Team ou GitHub Enterprise Cloud, habilitar as restrições de branches.

    • Selecione Restringir quem pode fazer push para os branches correspondentes. Branch restriction checkbox
    • Opcionalmente, para também restringir a criação de branches correspondentes, selecione Restringir pushes que criam branches correspondentes. Branch creation restriction checkbox
    • Pesquise e selecione pessoas, equipes ou apps que tenham permissão para fazer push para o branch protegido ou crie um branch correspondente. Branch restriction search
  15. Opcionalmente, em "Regras aplicadas a todos incluindo administradores", selecione Permitir pushes forçados. Permitir opção push forçado

    Em seguida, escolha quem pode fazer push forçado no branch.

    • Selecione Todos para permitir que todos com pelo menos permissões de escrita no repositório para forçar push para o branch, incluindo aqueles com permissões de administrador.

    • Selecione Especificar quem podefazer push forçado para permitir que apenas atores específicos façam push forçado no branch. Em seguida, pesquise e selecione esses atores. Captura de tela das opções para especificar que pode fazer push forçado

      Para obter mais informações sobre push forçado, consulte "Permitir pushes forçados".

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

  17. Clique em Criar.

Editar uma regra de proteção de branch

  1. No GitHub.com, 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. In the "Code and automation" section of the sidebar, click Branches.

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

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

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

Excluir as regras de proteção do branch

  1. No GitHub.com, 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. In the "Code and automation" section of the sidebar, click Branches.

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