Use a CODEOWNERS file to define individuals or teams that are responsible for code in a repository.
Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. When someone with admin permissions has enabled required reviews, they can optionally require approval from a code owner.
CODEOWNERS file location
To use a CODEOWNERS file, create a new file called CODEOWNERS in the root,
.github/ directory of the repository, in the branch where you'd like to add the code owners.
Each CODEOWNERS file assigns the code owners for a single branch in the repository. Thus, you can assign different code owners for different branches, such as
@octo-org/codeowners-team for a code base on the
master branch and
@octocat for a GitHub Pages site on the
For code owners to receive review requests, the CODEOWNERS file must be on the base branch of the 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
A CODEOWNERS file uses a pattern that follows the same rules used in gitignore files. The pattern is followed by one or more GitHub usernames or team names using the standard
@org/team-name format. You can also refer to a user by an email address that has been added to their GitHub account, for example
CODEOWNERS file example:
# This is a comment. # Each line is a file pattern followed by one or more owners. # These owners will be the default owners for everything in # the repo. Unless a later match takes precedence, # @global-owner1 and @global-owner2 will be requested for # review when someone opens a pull request. * @global-owner1 @global-owner2 # Order is important; the last matching pattern takes the most # precedence. When someone opens a pull request that only # modifies JS files, only @js-owner and not the global # owner(s) will be requested for a review. *.js @js-owner # You can also use email addresses if you prefer. They'll be # used to look up users just like we do for commit author # emails. *.go firstname.lastname@example.org # 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 # The `docs/*` pattern will match files like # `docs/getting-started.md` but not further nested files like # `docs/build-app/troubleshooting.md`. docs/* email@example.com # In this example, @octocat owns any file in an apps directory # anywhere in your repository. apps/ @octocat # In this example, @doctocat owns any file in the `/docs` # directory in the root of your repository. /docs/ @doctocat