Sobre proprietários do código
Você pode usar um arquivo CODEOWNERS para definir indivíduos ou equipes que são responsáveis pelo código em um repositório.
As pessoas com permissões de administrador ou proprietário podem configurar um arquivo CODEOWNERS em um repositório.
As pessoas que você escolhe como proprietários do código devem ter permissões de gravação para o repositório. When the code owner is a team, that team must have write permissions, even if all the individual members of the team already have write permissions directly, through organization membership, or through another team membership.
Os proprietários do código são solicitados automaticamente para revisão quando alguém abre uma pull request que modifica o código que eles têm.
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 "Habilitar revisões obrigatórias para pull requests".
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. Desse modo, é possível atribuir diferentes proprietários do código a diferentes branches, como @octo-org/codeowners-team para uma base de código no branch mestre e @octocat para um site do GitHub Pages no branch 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. For example, if you assign @octocat as the code owner for .js files on the gh-pages branch of your repository, @octocat will receive review requests when a pull request with changes to .js files is opened between the head branch and gh-pages.
Sintaxe de CODEOWNERS
Um arquivo CODEOWNERS usa um padrão que segue as mesmas regras usadas nos arquivos gitignore. 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. Você também pode consultar um usuário por um endereço de e-mail que tenha sido adicionado à respectiva conta do GitHub Enterprise, por exemplo user@example.com.
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
# Neste exemplo, @doctocat tem arquivos no diretório
# build/logs na raiz do repositório e qualquer um de seus
# subdiretórios.
/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
# Neste exemplo, @doctocat tem qualquer arquivo no diretório
# `/docs` na raiz do seu repositório.
/docs/ @doctocat