Regras disponíveis para conjuntos de regras

É possível criar conjuntos de regras para branch ou tags para controlar como os usuários podem interagir com as tags e os branches selecionados em um repositório. Também é possível criar conjuntos de regras por push para bloquear envios por push para um repositório privado ou interno e toda a rede de bifurcação do repositório.

Ao criar um conjunto de regras, você pode permitir que alguns usuários ignorem as regras do conjunto de regras. Podem ser usuários com determinadas funções, equipes específicas ou GitHub Apps.

Para conjuntos de regras por push, as permissões de bypass se aplicam a um repositório e a toda a rede de bifurcação do repositório. Isso significa que os únicos usuários que podem ignorar esse conjunto de regras para qualquer repositório em toda a rede de bifurcação desse repositório são os usuários que podem ignorar esse conjunto de regras no repositório raiz.

Para obter mais informações sobre como criar conjuntos de regras e permissões de bypass, confira Criar conjuntos de regras para um repositório.

Restringir as criações

Se isso estiver selecionado, somente os usuários com permissões de bypass poderão criar branches ou tags cujos nomes correspondam ao padrão especificado.

Restringir as atualizações

Se isso estiver selecionado, somente os usuários com permissões de bypass poderão enviar por push para branches ou tags cujos nomes correspondam ao padrão especificado.

Restringir as exclusões

Se isso estiver selecionado, somente os usuários com permissões de bypass poderão excluir branches ou tags cujos nomes correspondam ao padrão especificado. Essa regra está selecionada por padrão.

Exigir histórico linear

A imposição de um histórico de commits linear impede que os colaboradores efetuem push de commits de mesclagem em tags e branches direcionados. Isto significa que qualquer solicitação de pull mesclada no branch ou na tag precisa usar uma mesclagem squash ou uma mesclagem de troca de base. Um histórico de commit estritamente linear pode ajudar as equipes a reverter alterações mais facilmente. Para obter mais informações sobre métodos de mesclagem, confira Sobre fusões de pull-request.

Antes de exigir um histórico de commit linear, seu repositório deve permitir merge squash ou merge rebase. Para obter mais informações, confira Configurando a fusão de pull requests.

Exigir que as implantações tenham êxito antes da mesclagem

Você pode exigir que as alterações sejam implantadas com sucesso em ambientes específicos antes que um branch possa ser mesclado. Por exemplo, você pode usar essa regra para garantir que as alterações sejam implantadas com sucesso em um ambiente de preparo antes que as alterações sejam mescladas com o branch padrão.

Exigir commits assinados

Quando você habilitar a assinatura de commit obrigatória em um branch, os colaboradores e os bots só poderão efetuar push de commits que foram assinados e verificados no branch. Para obter mais informações, confira Sobre a verificação de assinatura de commit.

Quando você cria um branch, as regras e os conjuntos de regras de proteção de branch se comportam de maneira diferente: com conjuntos de regras, verificamos apenas os commits que não são acessíveis diretamente de outros branches. Por outro lado, com as regras de proteção de branch, não verificamos commits assinados a menos que você restrinja as transmissões que criem branches correspondentes. Para ambos, quando você atualizar uma ramificação, ainda verificaremos todos os commits no intervalo especificado, mesmo que um commit possa ser acessado de outras ramificações.

Em ambos os métodos, usamos a verified_signature? para confirmar se um commit tem uma assinatura válida. Caso contrário, a atualização não será aceita.

Observação

Se você habilitar o modo vigilante nas configurações da conta, o que indica que os commits serão sempre assinados, todos os commits que o GitHub identificar como "Parcialmente verificados" serão permitidos em branches que exijam commits assinados. Para obter mais informações sobre o modo vigilante, confira Exibindo status de verificação para todos os seus commits.
Se um colaborador fizer push de um commit não assinado para um branch que exige assinaturas de commit, o colaborador deverá fazer rebase do commit para incluir uma assinatura verificada e, em seguida, fazer push forçado no commit reescrito para o branch.

Você sempre pode fazer push de commits locais para o branch se os commits forem assinados e verificados. Também é possível mesclar commits assinados e verificados na ramificação usando uma solicitação de pull. No entanto, você não pode combinar por squash nem mesclar uma solicitação de pull na ramificação em GitHub, a menos que seja o autor da solicitação de pull . Você pode combinar por squash e mesclar as solicitações de pull localmente. Para obter mais informações, confira Fazer check-out de pull requests no local.

Para obter mais informações sobre métodos de mesclagem, confira Sobre métodos de mesclagem no GitHub.

Exigir uma solicitação de pull antes da mesclagem

Você pode exigir que todas as alterações no branch de destino sejam associadas a uma solicitação de pull. A solicitação de pull não precisa necessariamente ser aprovada, mas precisa ser aberta.

Configurações adicionais

Observação

Se você selecionar Ignorar aprovações de pull request obsoletas quando novas confirmações forem transmitidos e/ou Exigir aprovação do push revisável mais recente, a criação manual do commit de mesclagem de uma pull request e sua transmissão direta em um branch protegido apresentará falha, a menos que o conteúdo da mesclagem corresponda exatamente à mesclagem gerada por GitHub para a pull request.

Além disso, com essas configurações, a aprovação de revisões será ignorada como obsoleta se a base de mesclagem introduzir novas alterações depois que a revisão for enviada. A base de mesclagem é o commit que é o último ancestral comum entre o branch do tópico e o branch base. Se a base de mesclagem for alterada, a solicitação de pull não poderá ser mesclada até que alguém aprove o trabalho novamente.

Os administradores do repositório ou funções personalizadas com a permissão "edit repository rules" podem exigir que todas as solicitações de pull recebam um número específico de revisões de aprovação antes que alguém mescle a solicitação de pull em um branch protegido. Você pode exigir a aprovação de revisões de pessoas com permissões de gravação no repositório ou de um proprietário de código designado.

Se você habilitar as revisões obrigatórias, os colaboradores só poderão efetuar push das alterações em um branch por meio de uma solicitação de pull aprovada pelo número obrigatório de revisores com permissões de gravação.

Se alguém escolher a opção Solicitar alterações em uma revisão, ela precisará aprovar a solicitação de pull para que a solicitação de pull possa ser mesclada. Se um revisor que solicita alterações em um pull request não estiver disponível, qualquer pessoa com permissões de gravação no repositório poderá ignorar a revisão de bloqueio.

Opcionalmente, você pode optar por ignorar as aprovações obsoletas de solicitação de pull quando é efetuado o push de commits que afetam a comparação na solicitação de pull. O GitHub registra o estado da comparação no ponto em que uma solicitação de pull é aprovada. Esse estado representa o conjunto de alterações que o revisor aprovou. Se a comparação mudar desse estado (por exemplo, porque um colaborador efetua push de novas alterações para o branch de solicitação de pull ou clica em Atualizar branch ou porque uma solicitação de pull relacionada foi mesclada no branch de destino), a revisão de aprovação será descartada como obsoleta e a solicitação de pull não poderá ser mesclada até que alguém aprove o trabalho novamente. Para obter informações sobre a ramificação de destino, confira Sobre solicitação de pull.

Opcionalmente, você pode optar por exigir análises dos proprietários do código. Se você fizer isso, qualquer solicitação de pull que modifica o conteúdo com um proprietário do código precisará ser aprovada pelo proprietário desse código para que a solicitação de pull possa ser mesclada no branch protegido. Observe que, se o código tiver vários proprietários, uma aprovação de qualquer um dos proprietários de código será suficiente para atender a esse requisito. Para obter mais informações, confira Sobre os proprietários de código.

Como opção, você pode exigir uma aprovação de alguém que não seja a última pessoa a enviar por push para uma ramificação para que uma solicitação de pull possa ser mesclada. Isso representa que pelo menos um outro revisor autorizado aprovou alguma alteração. Por exemplo, o "último revisor" pode verificar se o conjunto mais recente de alterações incorpora os comentários de outras revisões e não adiciona um conteúdo novo e não revisado.

Para pull requests complexas que exigem muitas revisões, exigir uma aprovação de alguém que não seja a última pessoa a efetuar o push pode ser um meio-termo que evita a necessidade de ignorar todas as revisões obsoletas: com essa opção, as revisões "obsoletas" não são ignoradas e a pull request permanece aprovada desde que alguém que não seja a pessoa que fez as alterações mais recentes a aprove. Os usuários que já revisaram uma solicitação de pull podem reaprová-la após o push mais recente para atender a esse requisito. Se você tiver preocupações com o "sequestro" de pull requests (em que um conteúdo não aprovado é adicionado às pull requests aprovadas), será mais seguro ignorar as revisões obsoletas.

Opcionalmente, você pode exigir que todos os comentários na solicitação de pull sejam resolvidos para que ela seja mesclada em um branch. Isso garante que todos os comentários sejam resolvidos ou reconhecidos antes do merge.

Opcionalmente, você pode exigir um tipo de mesclagem por squash, rebase ou merge. Isso significa que os branches de destino só podem ser mesclados com base no tipo permitido. Além disso, se o repositório tiver desabilitado um método de mesclagem e o conjunto de regras exigir um método diferente, a mesclagem será bloqueada. Confira Sobre métodos de mesclagem no GitHub.

Revisores necessários

Opcionalmente, você pode exigir a revisão ou aprovação de equipes específicas quando uma solicitação de pull altera determinados arquivos ou diretórios. Você pode especificar até 15 equipes diferentes e, para cada equipe, você pode exigir um determinado número de aprovações dos membros da equipe.

O menu suspenso Revisor permite selecionar qualquer equipe que esteja no escopo onde a regra é definida.

        **Regras de toda a organização**: a equipe deve pertencer à organização.

        **Regras de nível de repositório**: a equipe deve pertencer à organização que possui o repositório.

Essa regra não está disponível em repositórios de propriedade do usuário, pois eles não contêm equipes.

As aprovações necessárias podem ser definidas de 0 (zero) a 10. Não exigir aprovações significa que a equipe será adicionada apenas para visibilidade, mas a equipe não precisa aprovar a solicitação.

Para cada equipe, você pode especificar uma lista de padrões de arquivo que determina a quais arquivos a configuração se aplica. O formato dessa lista de arquivos é o mesmo que um arquivo padrão .gitignore :

Um padrão que começa com um ponto de exclamação (!) é uma negação. Isso fará com que os caminhos que correspondem a padrões anteriores não exijam aprovações.
Os padrões são comparados em ordem, portanto, padrões negados podem "desfazer a correspondência" com arquivos que correspondiam a regras anteriores.

Exigir a aprovação nas verificações de status antes da mesclagem

As verificações de status obrigatórias garantem a aprovação em todos os testes de CI para que os colaboradores façam alterações em uma tag ou em um branch direcionado pelo seu conjunto de regras. As verificações de status obrigatórias podem ser verificações ou status. Para obter mais informações, confira Sobre verificações de status.

Use a API de status de commits para permitir que os serviços externos marquem os commits com um status apropriado. Para obter mais informações, confira Pontos de extremidade da API REST para status de commits.

Após a habilitação das verificações de status obrigatórias, todas as verificações de status obrigatórias precisarão ser aprovadas para que os colaboradores possam mesclar as alterações na tag ou no branch protegido.

Qualquer pessoa ou integração com permissões de gravação em um repositório pode definir o estado de qualquer verificação de status no repositório, mas em alguns casos você só pode aceitar uma verificação de status de um GitHub App específico. Ao adicionar uma regra de verificação de status obrigatória, você pode selecionar um aplicativo como a fonte esperada de atualizações de status. O aplicativo precisa ser instalado no repositório com a permissão statuses:write, precisa ter enviado uma execução de verificação recentemente e precisa estar associado a uma verificação de status obrigatória preexistente no conjunto de regras. Se o status for definido por qualquer outra pessoa ou integração, a mesclagem não será permitida. Se você selecionar "any source", ainda poderá verificar manualmente o autor de cada status, listado na caixa de mesclagem.

Para solucionar problemas com a configuração das verificações de status em conjuntos de regras, confira Regras de solução de problemas.

Você pode considerar as verificações de status obrigatórias como sendo "flexíveis" ou "estritas". O tipo de verificação de status obrigatória que você escolher determinará se o branch precisará ser atualizado com o branch base antes do merge.

Tipo de verificação de status obrigatória	Configuração	Requisitos de merge	Considerações

          **Estrito** | A caixa de seleção **Exigir a atualização dos branches antes da mesclagem** está marcada. | O branch do tópico **precisa** estar atualizado com o branch base antes da mesclagem. | Este é o comportamento padrão para verificações de status obrigatórias. Podem ser necessários mais builds, pois você precisará atualizar o branch principal depois que outros colaboradores atualizarem o branch de destino.|

| Flexível | A caixa de seleção Exigir a atualização dos branches antes da mesclagem****não está marcada. | O branch não precisa estar atualizado com o branch base antes da mesclagem. | Serão necessárias menos compilações, já que você não precisará atualizar o branch head depois que outros colaboradores fizerem merge de pull requests. As verificações de status poderão falhar depois que você fizer merge do branch, caso haja alterações incompatíveis com o branch base. | | Desabilitado | A caixa de seleção Exigir a aprovação de verificações de status antes da mesclagem****não está marcada. | O branch não tem restrições de merge. | Se as verificações de status obrigatórias não estiverem habilitadas, os colaboradores poderão fazer merge do branch a qualquer momento, estando ou não atualizados com o branch base. Isso aumenta a possibilidade de alterações incompatíveis.

Para obter informações sobre a solução de problemas com verificações de status, confira Solução de problemas para checagens de status obrigatórias.

Bloquear pushes forçados

Você pode impedir que os usuários forcem o push para os branches ou as tags de destino. Essa regra é habilitada por padrão.

Se alguém forçar pushes para um branch ou uma tag, os commits nos quais outros colaboradores basearam os respectivos trabalhos poderão ser removidos do histórico do branch ou da tag. Isso poderá resultar em conflitos de mesclagem ou em pull requests corrompidas. O push forçado também pode ser usado para excluir branches ou apontar um branch para commits que não foram aprovados em uma solicitação de pull.

A habilitação de pushes forçados não substituirá nenhuma outra regra de proteção de branch. Por exemplo, se um branch exigir um histórico de commit linear, você não poderá forçar commits a mesclar commits para esse branch.

Exigir resultados de code scanning

Se seus repositórios estiverem configurados com o code scanning, você poderá usar conjuntos de regras para evitar que pull requests sejam mescladas quando uma das seguintes condições for atendida:

Uma ferramenta necessária localiza um alerta code scanning de uma severidade definida no conjunto de regras.
A análise da ferramenta necessária ainda está em andamento.
Uma ferramenta necessária não está configurada para o repositório.

Para obter mais informações, confira Definir proteção contra mesclagem de verificação de código. Para obter informações mais gerais sobre o code scanning, confira Sobre a varredura de código.

Exigir resultados de qualidade de código

Se seus repositórios estiverem configurados com GitHub Code Quality, você poderá usar conjuntos de regras para impedir que as solicitações de pull sejam mescladas quando uma das seguintes condições for atendida:

A análise ainda está em andamento.
A análise falha por qualquer motivo, por exemplo: você esgotou seu orçamento para minutos de ações.
Code Quality encontrou um resultado de uma gravidade do nível definido no conjunto de regras ou de uma gravidade mais alta.

Para obter mais informações, confira Sobre a Qualidade do Código no GitHub e Definindo limites de qualidade de código para solicitações de pull.

Restringir caminhos de arquivo

Evita que commits que incluam alterações em caminhos de arquivo especificados sejam enviados por push ao repositório. O limite é de 200 entradas e até 200 caracteres em cada entrada.

É possível usar a sintaxe fnmatch para essa finalidade. Por exemplo, uma segmentação de restrição test/demo/**/* impede qualquer envio por push para arquivos ou pastas no diretório test/demo/. Uma segmentação de restrição test/docs/pushrules.md impede envios por push especificamente para o arquivo pushrules.md no diretório test/docs/. Para saber mais, confira Criar conjuntos de regras para um repositório.