Sobre os conjuntos de regras

Sobre os conjuntos de regras

Um conjunto de regras é uma lista nomeada de regras que se aplica a um repositório ou a vários repositórios de uma organização. É possível ter até 75 conjuntos de regras por repositório e 75 conjuntos de regras em toda a organização.

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 determinada função, como o administrador do repositório, ou podem ser equipes específicas ou GitHub Apps. Para saber mais sobre como conceder permissões de bypass, confira "Criar conjuntos de regras para um repositório".

É possível usar conjuntos de regras para direcionar branches ou tags em um repositório ou para bloquear envios por push para um repositório e para toda a rede de bifurcação do repositório.

Conjuntos de regras de branch e tag

Você pode criar conjuntos de regras para controlar como as pessoas podem interagir com tags e branches selecionados em um repositório. Você pode controlar ações como quem pode efetuar push de commits para determinado branch e como os commits precisam ser formatados ou quem pode excluir ou renomear uma tag. Por exemplo, você pode configurar um conjunto de regras para o branch feature do repositório que exige commits assinados e bloqueia pushes forçados para todos os usuários, exceto administradores do repositório.

Para cada conjunto de regras criado, especifique a quais tags ou branches no repositórioou a quais repositórios da sua organização, o conjunto de regras se aplica. Use a sintaxe fnmatch para definir um padrão para direcionar branches, tags e repositórios específicos. Por exemplo, você pode usar o padrão releases/**/* para direcionar todos os branches no repositório cujo nome começa com a cadeia de caracteres releases/. Para obter mais informações sobre a sintaxe de fnmatch, confira "Criar conjuntos de regras para um repositório".

Conjuntos de regras por push

Com os conjunto de regras por push, é possível bloquear envios por push para um repositório privado ou interno e para toda a rede de bifurcação desse repositório com base em extensões de arquivo, comprimentos de caminho de arquivo, caminhos de arquivo e pasta e tamanhos de arquivo.

As regras de push não exigem nenhum direcionamento de branch porque se aplicam a cada envio por push para o repositório.

Os conjuntos de regras por push permitem:

• Restringir caminhos de arquivo: impedir que confirmações que incluam alterações em caminhos de arquivo especificados sejam enviadas.

  É 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 obter mais informações, confira "Criar conjuntos de regras para um repositório".

• Restringir o comprimento do caminho do arquivo: impedir que confirmações que incluam caminhos de arquivo que excedam um limite de caracteres especificado sejam enviadas.

• Restringir extensões de arquivo: impedir que confirmações que incluam arquivos com extensões de arquivo especificadas sejam enviadas.

• Restringir o tamanho do arquivo: impedir que confirmações que excedam um limite de tamanho de arquivo especificado sejam enviadas.

Sobre os conjuntos de regras por push para repositórios bifurcados

As regras de push se aplicam a toda a rede de bifurcação de um repositório, garantindo que cada ponto de entrada do repositório esteja protegido. Por exemplo, se você bifurcar um repositório que tenha conjuntos de regras por push habilitados, os mesmos conjuntos de regras por push também se aplicarão ao repositório bifurcado.

Para um repositório bifurcado, as únicas pessoas que têm permissões de bypass para uma regra de push são as pessoas que têm permissões de bypass no repositório raiz.

Sobre os conjuntos de regras e as tags e os branches protegidos

Os conjuntos de regras funcionam com qualquer regra de proteção de branch e de tag em um repositório. Muitas das regras que você pode definir em conjuntos de regras são semelhantes às regras de proteção, e você pode começar a usar conjuntos de regras sem substituir nenhuma das regras de proteção existentes.

Além disso, você pode importar as regras de proteção de tag existentes para os conjuntos de regras do repositório. Isso implementará as mesmas proteções de tag que você atualmente tem em vigor para seu repositório. Confira "Configurar regras de proteção para tags".

Os conjuntos de regras têm as vantagens a seguir em relação às regras de proteção de branch e de tag.

• Ao contrário das regras de proteção, vários conjuntos de regras podem ser aplicados ao mesmo tempo, ou seja, você pode ter certeza de que todas as regras direcionadas a um branch ou uma tag no repositório serão avaliadas quando alguém interagir com esse branch ou essa tag. Consulte “Sobre as camadas de regras”.
• Os conjuntos de regras têm status, ou seja, você pode gerenciar com facilidade os conjuntos de regras que estão ativos em um repositório sem a necessidade de excluir conjuntos de regras.
• Qualquer pessoa com acesso de leitura em um repositório pode visualizar os conjuntos de regras ativos do repositório. Isso significa que um desenvolvedor pode entender por que atingiu uma regra ou um auditor pode verificar as restrições de segurança do repositório, sem exigir acesso de administrador no repositório.
• É possível criar regras adicionais para controlar os metadados de commits que entram em um repositório, como a mensagem do commit e o endereço de email do autor. Consulte "Regras disponíveis para conjuntos de regras" na GitHub Enterprise Cloud documentação.

Usar status de imposição de conjunto de regras

Ao criar ou editar seu conjunto de regras, você pode usar status de imposição para configurar como seu conjunto de regras será imposto.

Você pode selecionar qualquer um dos seguintes status de imposição para seu conjunto de regras.

• Ativo: seu conjunto de regras será imposto após a criação.
• Avaliar: seu conjunto de regras não será aplicado, mas você poderá monitorar quais ações violariam ou não as regras na página "Insights de regras".
• Desabilitado: seu conjunto de regras não será imposto ou avaliado.

Usar o modo "Avaliar" é uma ótima opção para testar seu conjunto de regras sem impô-lo. É possível usar a página "Insights da regra" para ver se a contribuição teria violado a regra. Para obter mais informações, confira "Gerenciar conjuntos de regras para um repositório".

Sobre as camadas de regras

Um conjunto de regras não tem prioridade. Em vez disso, se vários conjuntos de regras forem direcionados ao mesmo branch ou à mesma tag em um repositório, as regras de cada um desses conjuntos de regras serão agregadas. Se a mesma regra for definida de maneiras diferentes entre os conjuntos de regras agregados, a versão mais restritiva da regra se aplicará. Além de serem colocados em camadas entre si, os conjuntos de regras também são colocados em camadas com regras de proteção direcionadas ao mesmo branch ou à mesma tag.

Por exemplo, considere a situação a seguir para o branch my-feature do repositório octo-org/octo-repo.

• Um administrador do repositório configurou um conjunto de regras direcionado ao branch my-feature. Esse conjunto de regras exige commits assinados e três revisões em pull requests para que elas sejam mescladas.
• Uma regra de proteção de branch existente para o branch my-feature exige um histórico de commits linear e duas revisões em pull requests para que sejam mescladas.
• Um administrador da organização octo-org também configurou um conjunto de regras direcionado ao branch my-feature do repositório octo-repo. O conjunto de regras bloqueia pushes forçados e exige uma revisão nas pull requests para que elas sejam mescladas.

As regras de cada origem são agregadas, e todas as regras se aplicam. Quando existem várias versões diferentes da mesma regra, o resultado é que a versão mais restritiva da regra se aplica. Portanto, o branch my-feature exige commits assinados e um histórico de commits linear, os pushes forçados são bloqueados e as pull requests direcionadas ao branch exigirão três revisões para que sejam mescladas.