Observação
As políticas de repositório estão em versão prévia pública e estão sujeitas a alterações. Você pode ter até 75 conjuntos de regras e políticas no total por organização e até 75 conjuntos de regras e políticas no total por empresa.
Para controlar os principais eventos no ciclo de vida dos repositórios, como quem pode criar ou excluí-los, você pode criar uma política de repositório. Uma política de repositório é uma coleção de restrições que oferece controle flexível sobre quais usuários são afetados e quais repositórios são alvos.
Em uma política de repositório, você pode restringir:
- Quais visibilidades são permitidas para novos repositórios e alterações de visibilidade.
- Quem pode criar repositórios.
- Quem pode excluir repositórios.
- Quem pode transferir repositórios para fora da organização.
- Como as pessoas podem nomear os repositórios.
Dica
Se você é um proprietário da organização, pode criar uma política de repositório para uma organização específica. Confira Controlando como as pessoas usam repositórios em sua organização.
Exemplos
Você pode usar uma política de repositório para fazer coisas como:
- Garantir que todos os novos repositórios usem uma determinada convenção de nomenclatura, como
kebab-case. - Impedir exclusões de repositório, exceto por administradores da organização.
- Permitir que repositórios públicos sejam criados apenas na organização de "código aberto" em sua empresa.
- Impedir que repositórios públicos sejam alterados para privados para evitar a perda potencial de metadados.
Como definirei repositórios como alvo?
Primeiro, você definirá como alvo as organizações de sua empresa. Você pode selecionar todas as organizações, escolher em uma lista ou criar uma regra dinâmica usando a sintaxe fnmatch. Se você usar o Enterprise Managed Users, também poderá optar por definir como destino todos os repositórios de propriedade dos usuários de sua empresa.
Em seguida, você definirá como alvo os repositórios nas organizações selecionadas. É recomendável usar políticas de repositório juntamente com propriedades de repositório personalizadas. Ao adicionar propriedades personalizadas a repositórios, você poderá definir de maneira flexível os repositórios que são alvo de uma política.
Por exemplo, você pode adicionar uma propriedade para marcar repositórios que contêm dados de produção ou outras informações confidenciais e impedir que qualquer pessoa torne esses repositórios públicos.
Para criar e definir propriedades personalizadas, confira Como gerenciar propriedades personalizadas para repositórios na sua organização.
Interação com outras políticas
Algumas das restrições disponíveis são duplicatas de políticas que você pode ter definido na página "Member privileges" nas configurações da organização ou da empresa.
A criação de uma política de repositório não substitui suas políticas existentes de "privilégio de membro". Em vez disso, as políticas são aditivas, de modo que a versão mais restritiva de uma política se aplica. Isso se aplica tanto a políticas de privilégio de membro quanto a outras políticas de repositório que as pessoas criaram no nível da empresa ou da organização.
Em comparação com as políticas de privilégio de membro, as políticas de repositório têm várias vantagens:
- Elas oferecem uma definição mais flexível de organizações e repositórios alvo.
- Elas permitem que você dê a determinados atores a opção de ignorar as políticas.
- Elas são visíveis para os proprietários da organização, de modo que há mais transparência com relação ao que é permitido.
- Elas permitem que você defina como alvo repositórios de propriedade do Enterprise Managed Users.
Criando uma política de repositório
- No canto superior direito do GitHub, selecione sua imagem de perfil.
- Dependendo do ambiente, selecione Sua empresa ou Suas empresas e escolha a empresa que deseja ver.
- Na parte superior da página, clique em Policies.{ % else %}No lado esquerdo da página, na barra lateral da conta empresarial, clique em Policies.
- Em "Policies", clique em Repository.
- Clique em Nova política.
- Configure a nova política e clique em Create. Para obter ajuda, consulte as subseções a seguir.
Nome de política
Use algo descritivo para indicar a finalidade da política. Os proprietários da organização podem exibir a política, portanto, bons nomes ajudam a conferir clareza. Por exemplo: Prevent public repos on production.
Status da imposição
Se não quiser que a política seja imposta quando ela for criada, defina como "Disabled". Caso contrário, defina como "Active".
Lista de permissões
Escolha quais funções podem ignorar as restrições nesta política.
Destinos
Escolha a quais organizações e repositórios a política se aplica.
Organizações alvo
Selecione todas as organizações, faça uma seleção entre as organizações existentes ou defina uma lista dinâmica por nome. Se você usar o Enterprise Managed Users, também poderá optar por definir como destino todos os repositórios de propriedade dos usuários de sua empresa.
Se você definir uma lista dinâmica, adicionará um ou mais padrões de nomenclatura usando a sintaxe fnmatch. Por exemplo, a cadeia de caracteres *open-source corresponderia a qualquer organização com um nome terminado em open-source. Para obter detalhes da sintaxe, confira Criar conjuntos de regras para um repositório.
Repositórios alvo
Escolha quais repositórios (atuais ou futuros) serão alvos nas organizações selecionadas. Você pode selecionar todos os repositórios ou definir uma lista dinâmica por propriedade personalizada.
Políticas
Escolha quais restrições são incluídas. Quando a política está ativa, restrições se aplicam a todos os repositórios de destino, mas podem ser ignoradas por usuários ou equipes na lista de permissões.
Se você escolher a política "Restrict names", precisará usar a sintaxe de expressão regular para definir um padrão a que os nomes do repositório devem ou não corresponder. Por exemplo, um padrão para impor a nomenclatura kebab-case seria semelhante a ^([a-z][a-z0-9]*)(-[a-z0-9]+)*$.
- Os padrões dão suporte à sintaxe RE2. Consulte o guia de sintaxe do Google.
- Para validar suas expressões, clique em Test pattern e insira um padrão e um valor de teste.
Como delegar o bypass de políticas
Observação
O bypass delegado de políticas de repositório estão em versão prévia pública e estão sujeitas a alterações.
O bypass delegado para políticas de repositório permite controlar quem pode ignorar políticas de repositório no caso de exclusões e alterações de visibilidade de repositórios.
Com o bypass delegado, os administradores do repositório precisam enviar uma solicitação para alterar a visibilidade do repositório ou exclui-lo. A solicitação é enviada a um grupo designado de revisores, que aprovam ou negam a solicitação para ignorar políticas do repositório.
Se a solicitação para ignorar políticas do repositório for aprovada, a alteração da solicitação será concluída imediatamente. Se a solicitação for negada, a alteração solicitada não será feita, mas poderá ser solicitada novamente.
Para configurar o bypass delegado, os proprietários da empresa ou da organização criam primeiro uma "lista de bypass". A lista de desvio inclui funções e equipes específicas, como administradores de equipe ou de repositório, que supervisionam as solicitações de bypass de políticas do repositório. Para saber mais, confira Controlando como as pessoas usam repositórios em sua empresa.
Como gerar solicitações de bypass
Gerenciamento de solicitações para ignorar regras de push
Observação
O bypass delegado de políticas de repositório estão em versão prévia pública e estão sujeitas a alterações.
Você pode visualizar e gerenciar todas as solicitações de privilégios de bypass na página "Bypass Requests", localizada nas configurações de Policy.
Você pode filtrar solicitações por aprovador (membro da lista de bypass), solicitante (colaborador que faz a solicitação), prazo e status. Os seguintes status são atribuídos a uma solicitação:
| Status | Descrição |
|---|---|
Cancelled | A solicitação foi cancelada pelo contribuidor. |
Completed | A solicitação foi aprovada, e os commits foram enviados por push para o repositório. |
Denied | A solicitação foi analisada e negada. |
Expired | A solicitação expirou. As solicitações são válidas por 7 dias. |
Open | A solicitação ainda não foi examinada ou foi aprovada, mas os commits não foram enviados por push para o repositório. |
Quando um contribuidor solicita privilégios de bypass para enviar um commit com conteúdo restrito, todos os membros da lista de bypass recebem uma notificação por email com um link para a solicitação. Os membros da lista de bypass terão 7 dias para examinar e aprovar ou negar a solicitação antes que ela expire.
O contribuidor é notificado da decisão por email e deve tomar as medidas necessárias. Se a solicitação for aprovada, o contribuidor poderá enviar o commit com conteúdo restrito para o repositório. Se a solicitação for negada, o contribuidor deverá remover o conteúdo restrito do commit para enviar o commit com êxito ao repositório.
Leitura adicional
Para definir políticas adicionais para o gerenciamento de repositório, confira Aplicar as políticas de gerenciamento do repositório na sua empresa.