Introdução
Você pode criar conjuntos de regras na sua organização para controlar como os usuários podem interagir com os repositórios na sua organização. 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. Você também pode impedir que as pessoas renomeiem repositórios.
Ao criar um conjunto de regras para uma organização, use a sintaxe fnmatch
para definir quais repositórios na sua organização e quais tags ou branches nesses repositórios são direcionados pelo conjunto de regras. Isso fornece uma maneira mais rápida de direcionar repositórios em sua organização do que criar um conjunto de regras separado para cada repositório. Para obter mais informações, confira "Sobre padrões fnmatch
para branches, tags e repositórios".
Os forks não herdam conjuntos de regras dos respectivos repositórios upstream. No entanto, os forks pertencentes à sua organização estão sujeitos aos conjuntos de regras que você cria, como qualquer outro repositório.
Você pode importar um conjunto de regras de outro repositório ou organização usando um arquivo JSON. Isso pode ser útil se você quiser aplicar o mesmo conjunto de regras a vários repositórios ou organizações. Para obter mais informações, consulte "Como gerenciar conjuntos de regras para repositórios na sua organização".
Para criar um conjunto de regras, conclua os procedimentos a seguir:
- Criar um conjunto de regras de branch ou tag
- Conceder permissões de bypass para seu conjunto de regras
- Escolher quais repositórios direcionar em sua organização
- Escolher quais branches ou tags direcionar
- Selecionar proteções de branch ou tag
- Adicionar restrições de metadados
- Finalizar seu conjunto de regras e próximas etapas
Criar um conjunto de regras de branch ou tag
-
No canto superior direito do GitHub.com, selecione sua foto do perfil e em Suas organizações.
-
Ao lado da organização, clique em Configurações.
-
Na barra lateral esquerda, na seção "Código, planejamento e automação", clique em Repositório e em Conjuntos de regras do repositório.
-
Você pode criar um conjunto de regras direcionado a branches ou a tags.
-
Para criar um conjunto de regras direcionado a branches, clique em Novo conjunto de regras de branch.
-
Para criar um conjunto de regras direcionado a tags, selecione e clique em Novo conjunto de regras de tag.
-
-
Na seção "Geral", digite um nome para o conjunto de regras, selecione Desabilitado e clique em um dos seguintes status de imposição:
- 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". Para obter mais informações, confira "Como exibir os insights dos conjuntos de regras".
- Desabilitado: seu conjunto de regras não será imposto ou avaliado.
Conceder permissões de bypass para seu conjunto de regras
Você pode conceder permissões de ignorar determinadas funções, equipes ou aplicativos para seu conjunto de regras. Os seguintes itens são qualificados para acesso de bypass:
- Administradores de repositório ou proprietários de organizações
- A função de manutenção ou gravação ou funções de repositório personalizadas com base na função de gravação
- Teams
- GitHub Apps
-
Para conceder permissões de bypass para o conjunto de regras, na seção "Lista de bypass", clique em e depois clique em Somente para solicitações de pull.
O ator selecionado agora é obrigado a abrir uma solicitação de pull para fazer alterações em um repositório, criando uma trilha digital clara com suas alterações. O ator pode então optar por ignorar quaisquer proteções de branch e mesclar essa solicitação de pull.
Escolher quais repositórios direcionar em sua organização
Com seu conjunto de regras, você pode optar por direcionar todos os repositórios em sua organização, repositórios em sua organização que correspondam a uma determinada convenção de nomenclatura ou uma lista de repositórios selecionados manualmente em sua organização.
Se um repositório for direcionado por um conjunto de regras criado no nível da organização, somente os proprietários da organização poderão editar o conjunto de regras. No entanto, as pessoas com acesso de administrador no repositório ou com uma função personalizada, incluindo a permissão "Editar regras do repositório", podem criar conjuntos de regras adicionais no nível do repositório. As regras nesses conjuntos de regras serão agregadas às regras definidas no nível da organização. O resultado é que a criação de um conjunto de regras pode tornar as regras direcionadas a uma tag ou a um branch mais restritivas, mas nunca menos restritivas. Para obter mais informações sobre como criar conjuntos de regras, confira "Sobre os conjuntos de regras".
Direcionar todos os repositórios em sua organização
Para direcionar todos os repositórios em sua organização, na seção "Repositórios de destino", selecione Destino: REPOSITÓRIOS e, em seguida, clique em Todos os repositórios.
Direcionar repositórios por convenção de nomenclatura em sua organização
-
Para direcionar uma lista dinâmica de repositórios em sua organização por convenção de nomenclatura, na seção "Repositórios de destino", selecione Destino: REPOSITÓRIOS e, em seguida, clique em Lista dinâmica de repositórios.
-
Para começar a definir um padrão de direcionamento, na seção "Critérios de direcionamento", selecione Adicionar um destino e clique em Incluir por padrão ou Excluir por padrão.
-
Na caixa de diálogo modal exibida, insira um padrão de nomenclatura de repositório usando a sintaxe
fnmatch
e clique em Adicionar padrão de inclusão ou Adicionar padrão de exclusão. Para obter mais informações sobre a sintaxefnmatch
, confira "Usar a sintaxefnmatch
".Nota: você pode adicionar vários critérios de direcionamento ao mesmo conjunto de regras. Por exemplo, você pode incluir todos os repositórios que correspondam ao padrão
*cat*
e excluir especificamente um repositório que corresponda ao padrãonot-a-cat
. -
Opcionalmente, na página de configuração do conjunto de regras, selecione Impedir renomeação de repositórios de destino.
Como direcionar repositórios por propriedades em sua organização
Nota: as propriedades do repositório estão na versão beta pública e sujeitas a alterações.
Você pode direcionar repositórios em sua organização por propriedades personalizadas. Para obter mais informações, confira "Como gerenciar propriedades personalizadas para repositórios na sua organização".
- Para direcionar uma lista dinâmica de repositórios em sua organização por propriedades, na seção "Repositórios de destino", selecione Destino: REPOSITÓRIOS e, em seguida, clique em Lista dinâmica por propriedade.
- Para adicionar um destino, na seção "Critérios de direcionamento", selecione Adicionar um destino e clique em Incluir por propriedade ou Excluir por propriedade.
- Na caixa de diálogo modal exibida, selecione uma propriedade no menu suspenso e um valor para a propriedade.
- Clique em Adicionar destino.
Direcionar repositórios selecionados em sua organização
- Para direcionar uma lista de repositórios estáticos selecionados manualmente em sua organização, na seção "Repositórios de destino", selecione Destino: REPOSITÓRIOS e, em seguida, clique em Selecionar repositórios.
- Para selecionar os repositórios a direcionar, na seção "Critérios de direcionamento", selecione Selecionar repositórios e procure o nome de cada repositório a ser direcionado. Selecione cada repositório nos resultados da pesquisa.
Escolher quais branches ou tags direcionar
Para direcionar branches ou tags na seção "Branches de destino" ou "Tags de destino", selecione Adicionar um destino e escolha como deseja incluir ou excluir branches ou tags. Use a sintaxe fnmatch
para incluir ou excluir branches ou tags com base em um padrão. Para obter mais informações, confira "Como usar a sintaxe fnmatch
".
Você pode adicionar vários critérios de direcionamento ao mesmo conjunto de regras. Por exemplo, você pode incluir o branch padrão, incluir os branches que correspondam ao padrão *feature*
e excluir especificamente um branch que corresponda ao padrão not-a-feature
.
Selecionar proteções de branch ou tag
Na seção "Proteções de branch" ou "Proteções de tag", selecione as regras que deseja incluir no conjunto de regras. Ao selecionar uma regra, você poderá inserir configurações adicionais para ela. Para obter mais informações sobre as regras, confira "Regras disponíveis para conjuntos de regras".
Observações: se você selecionar Exigir verificações de status antes da mesclagem, na seção "Configurações adicionais":
- Você poderá inserir o nome de cada verificação de status que deseja exigir. Para terminar de adicionar a verificação de status como um requisito, você deve clicar em .
- Se você selecionar Exigir que branches sejam atualizados antes da mesclagem, deverá definir uma verificação para que a proteção entre em vigor.
Adicionar restrições de metadados
Observações:
- A adição de restrições de metadados pode afetar a experiência das pessoas que contribuem para seu repositório. Antes de aplicar um conjunto de regras com restrições de metadados, você pode selecionar o status de imposição "Avaliar" para o conjunto de regras testar os efeitos de quaisquer restrições de metadados sem afetar os colaboradores. Para obter mais informações sobre as restrições de metadados, confira "Regras disponíveis para conjuntos de regras".
- As restrições de metadados se destinam a aumentar a consistência entre os commits no seu repositório. Elas não se destinam a substituir medidas de segurança, como exigir uma revisão de código por meio de solicitações de pull.
- Se você fizer uma mesclagem squash para uma ramificação, os commits nessa ramificação devem atender a todos os requisitos de metadados para a ramificação base.
-
Opcionalmente, na seção "Restrições de metadados", para adicionar uma regra para controlar os metadados de commits que estão sendo enviados por push para o branch ou a tag, clique em .
-
Defina as configurações para a regra de restrição de metadados e clique em Adicionar. Você pode adicionar várias restrições ao mesmo conjunto de regras.
Para a maioria dos requisitos, como "Precisa começar com um padrão correspondente", o padrão inserido é interpretado literalmente e não há suporte para curingas. Por exemplo, o caractere
*
representa apenas o caractere literal*
.Para padrões mais complexos, você pode selecionar "Precisa corresponder a determinado padrão regex" ou "Não precisa corresponder a determinado padrão regex" e usar a sintaxe de expressão regular para definir o padrão correspondente. Para obter mais informações, confira "Como usar expressões regulares para metadados de commit".
Qualquer pessoa que visualizar os conjuntos de regras de um repositório poderá ver a descrição fornecida por você.
Finalizar seu conjunto de regras e próximas etapas
Para concluir a criação do conjunto de regras, clique em Criar. Se o status de imposição do conjunto de regras for definido como "Ativo", o conjunto de regras entrará em vigor imediatamente.
Você pode exibir insights para o conjunto de regras para ver como as regras estão afetando seus colaboradores. Se o status de imposição estiver definido como "Avaliar", você poderá ver quais ações teriam passado ou falhado se o conjunto de regras estivesse ativo. Para obter mais informações sobre insights para conjuntos de regras, confira "Gerenciar conjuntos de regras para um repositório".
Sobre padrões fnmatch
para branches, tag e repositórios
Use a sintaxe fnmatch
para definir padrões direcionados aos nomes de branches, tags e repositórios ao criar um conjunto de regras.
Use o curinga *
para encontrar a correspondência de qualquer cadeia de caracteres. Como o GitHub usa o sinalizador File::FNM_PATHNAME
para a sintaxe File.fnmatch
, o curinga *
não corresponde aos separadores de diretório (/
). Por exemplo, qa/*
corresponderá a todos os branches que começam com qa/
e que contêm uma barra "/", mas não corresponderá a qa/foo/bar
. Você pode incluir qualquer quantidade de barras "/" após qa
com qa/**/*
, o que corresponderá, por exemplo, a qa/foo/bar/foobar/hello-world
. Você também pode estender a cadeia de caracteres qa
com qa**/**/*
para tornar a regra mais inclusiva.
Para obter mais informações sobre as opções de sintaxe, confira a documentação de fnmatch.
Observação: embora GitHub seja compatível com File::FNM_PATHNAME
na sintaxe fnmatch
, não há suporte para File::FNM_EXTGLOB
.
Sobre expressões regulares para metadados de commit
Ao adicionar restrições de metadados, use a sintaxe de expressão regular para definir a quais padrões os metadados relevantes, como a mensagem do commit ou o nome do branch ou da tag, precisam ou não corresponder.
Os conjuntos de regras dão suporte à sintaxe RE2. Para obter mais informações, confira o guia de sintaxe do Google. Para validar as expressões, use o validador em regex101.com selecionando a variante "Golang" na barra lateral esquerda.
Por padrão, expressões regulares em restrições de metadados não consideram várias linhas de texto. Por exemplo, se você tiver uma mensagem do commit de várias linhas, o padrão ^ABC
será uma correspondência se qualquer linha da mensagem começar com ABC
. Para corresponder a várias linhas da mensagem, comece sua expressão com (?m)
.
Não há suporte para a declaração lookahead negativa, indicada como ?!
. No entanto, para os casos em que você precisa procurar determinada cadeia de caracteres que não é seguida de outra cadeia de caracteres especificada, use a asserção lookahead positiva, indicada como ?
, combinada com o requisito "Não deve corresponder a determinado padrão regex".
Observação: se você precisar que os colaboradores assinem commits, isso poderá interferir nos padrões de expressão regular. Quando alguém sai do serviço, o GitHub adiciona uma cadeia de caracteres como Signed-off-by: #AUTHOR-NAME <#AUTHOR-EMAIL>
à mensagem de commit. Para obter mais informações, confira "Como gerenciar a política de aprovação de confirmação para sua organização".
Padrões úteis de expressão regular
Os exemplos a seguir fornecem padrões úteis para metadados de commit. Para usar esses padrões, defina Requisito como "Precisa corresponder a um determinado padrão de regex".
Garantir que os nomes de branches sejam compatíveis com o Windows
Use o padrão a seguir para garantir que os nomes dos branches incluam apenas números, letras minúsculas e os caracteres -
e _
. Isso garante que os nomes dos branches sejam compatíveis com sistemas operacionais que não usam sistemas de arquivos que diferenciam maiúsculas de minúsculas por padrão.
\A[0-9a-z-_]$
\A[0-9a-z-_]$
Corresponde a: my-branch
Não corresponde: myBranch
Garantir que os nomes de tags usem um controle de versão semântico
Use o padrão a seguir para garantir que os nomes das tags estejam em conformidade com o controle de versão semântico. Para obter mais informações, confira a documentação em semver.org.
^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$
^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$
Corresponde a: 1.2.3
, 10.20.30
e 1.1.2-prerelease+meta
Não corresponde: 1.2
, 1.2-SNAPSHOT
Limitar o comprimento das linhas em mensagens de commit
O livro Pro Git recomenda limitar a primeira linha de uma mensagem de commit a cerca de 50 caracteres.
Use o padrão a seguir para garantir que a primeira linha em uma mensagem de commit contenha 50 caracteres ou menos.
\A.{1,50}$
\A.{1,50}$
Garantir que as mensagens do commit comecem com uma resolução e um número de problema
Use o padrão a seguir para garantir que as mensagens de commit contenham a palavra Resolves:
ou Fixes:
, seguido de uma cadeia de caracteres como #1234
.
^(Resolves|Fixes): \#[0-9]+$
^(Resolves|Fixes): \#[0-9]+$
Corresponde a: Fixes: #1234
Não corresponde: Add conditional logic to foo.bar
Impor commits convencionais
Use o padrão a seguir para garantir que as mensagens de commit estejam em conformidade com a especificação Commits Convencionais. Para obter mais informações, confira conventionalcommits.org.
^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)
^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)
Corresponde a: feat: allow provided config object to extend other configs
Não corresponde: Add conditional logic to foo.bar