As pessoas com permissões de administrador ou proprietário podem configurar um arquivo CODEOWNERS em um repositório.
As pessoas escolhidas como proprietários do código devem ter permissões de leitura para o repositório. Quando o proprietário do código é uma equipe, essa equipe deverá ser visível e ter permissões de gravação, ainda que todos os membros individuais da equipe já tenham permissões de gravação diretamente, por meio da associação da organização ou por meio de outra associação � equipe.
Sobre proprietários do código
Solicita-se automaticamente que os proprietários do código revisem quando alguém abre um pull request que modifica o código que possuem. Solicita-se automaticamente que os proprietários do código revejam os rascunhos de pull requests. Para obter mais informações sobre pull requests em rascunho, consulte "Sobre pull requests". Solicita-se automaticamente que os proprietários do código revejam os rascunhos de pull requests. Se você converter um pull request em rascunho, as pessoas que já assinaram as notificações não terão suas assinaturas canceladas automaticamente. Para obter mais informações, consulte "Alterar o stage de um pull request".
Quando alguém com permissões de administrador ou proprietário tiver habilitado revisões obrigatórias, se desejar, ele também poderá exigir aprovação de um proprietário do código para que o autor possa fazer merge de uma pull request no repositório. Para obter mais informações, consulte "Sobre branches protegidos".
Se um arquivo tiver um proprietário do código, você poderá ver quem é o proprietário do código antes de abrir um pull request. No repositório, é possível pesquisar o arquivo e passar o mouse sobre o .
Local do arquivo CODEOWNERS
Para usar um arquivo CODEOWNERS, crie um novo arquivo denominado CODEOWNERS na raiz, docs/ ou no diretório .github/ do repositório, no branch em que deseja adicionar os proprietários do código.
Cada arquivo CODEOWNERS atribui os proprietários do código para um único branch no repositório. Dessa forma, você pode atribuir diferentes proprietários de códigos para diferentes branches, como @octo-org/codeowners-team para uma base de código no branch-padrão e @octocat para um site do GitHub Pages no branch de gh-pages.
Para que os proprietários do código recebam solicitações de revisão, o arquivo CODEOWNERS deve estar no branch base da pull request. Por exemplo, se você atribuir @octocat como o proprietário do código para arquivos .js no branch gh-pages do seu repositório, @octocat receberá solicitações de revisão quando uma pull request com alterações nos arquivos .js for aberta entre o branch head e gh-pages.
Sintaxe de CODEOWNERS
Um arquivo CODEOWNERS usa um padrão que segue a maioria das mesmas regras usadas nos arquivos gitignore, com algumas exceções. O padrão é seguido por um ou mais nomes de usuário ou nomes de equipe do GitHub usando o formato padrão @username ou @org/team-name. Os usuários devem ter acessso de leitura ao repositório e as equipes devem ter acesso explícito de gravação, mesmo que os integrantes da equipe já tenham acesso.
Você também pode se referir a um usuário por um endereço de e-mail que foi adicionado a sua conta em your GitHub Enterprise Server instance, por exemplo, user@example tom.
Os caminhos dos CODEOWNERS diferenciam maiúsculas de minúsculas, porque GitHub usa um sistema de arquivos que diferencia maiúsculas e minúsculas. Uma vez que os CODEOWNERS são avaliados por GitHub, até mesmo sistemas que diferenciam maiúsculas de minúsculas (por exemplo, macOS) devem usar caminhos e arquivos que são tratados corretamente no arquivo dos CODEOWNERS.
Se qualquer linha do seu arquivo CODEOWNERS contiver uma sintaxe inválida, o arquivo não será detectado e não será usado para solicitar revisões.
Exemplo de um arquivo CODEOWNERS
# Este é um comentário.
# Cada linha é um padrão de arquivo seguido por um ou mais proprietários.
# Esses proprietários serão os proprietários padrão para tudo no
# repositório. A menos que uma correspondência posterior tenha precedência,
# @global-owner1 e @global-owner2 serão solicitados para
# revisão quando alguém abrir uma pull request.
* @global-owner1 @global-owner2
# A ordem é importante; o último padrão de correspondência tem
# prioridade. Quando alguém abre uma pull request que
# modifica apenas arquivos JS, somente @js-owner, e não o(s)
# proprietário(s) global(is), será solicitado para uma revisão.
*.js @js-owner
# Você também pode usar endereços de e-mail se preferir. Eles serão
# usados para procurar usuários assim como fazemos com e-mails do
# autor do commit.
*.go docs@example.com
# Teams can be specified as code owners as well. Teams should
# be identified in the format @org/team-name. Teams must have
# explicit write access to the repository. In this example,
# the octocats team in the octo-org organization owns all .txt files.
*.txt @octo-org/octocats
# In this example, @doctocat owns any files in the build/logs
# directory at the root of the repository and any of its
# subdirectories.
/build/logs/ @doctocat
# O padrão `docs/*` corresponderá a arquivos como
# `docs/getting-started.md`, mas a nenhum outro arquivo aninhado como
# `docs/build-app/troubleshooting.md`.
docs/* docs@example.com
# Neste exemplo, @octocat tem qualquer arquivo no diretório apps
# em qualquer lugar do seu repositório.
apps/ @octocat
# In this example, @doctocat owns any file in the `/docs`
# directory in the root of your repository and any of its
# subdirectories.
/docs/ @doctocat
# In this example, any change inside the `/scripts` directory
# will require approval from @doctocat or @octocat.
/scripts/ @doctocat @octocat
# In this example, @octocat owns any file in the `/apps`
# directory in the root of your repository except for the `/apps/github`
# subdirectory, as its owners are left empty.
/apps/ @octocat
/apps/github
Exceções de sintaxe
Existem algumas regras de sintaxe para arquivos gitignore que não funcionam em arquivos CODEOWNERS:
- Fugir de um padrão que começa com
#usando\para que seja tratado como um padrão e não como um comentário - Usar
!para negar um padrão - Usar
[ ]para definir um intervalo de caracteres
Proteção de branch e de CODEOWNERS
Os proprietários do repositório podem adicionar regras de proteção de branch para garantir que o código alterado seja revisado pelos proprietários dos arquivos alterados. Para obter mais informações, consulte "Sobre branches protegidos."