Usage

# Either put this in a file called CODEOWNERS or .bitbucket/CODEOWNERS
# Lines starting with # are comments.

# Configuration lines start with CODEOWNERS.

# To restrict code owners functionality for a certain destination branch,
# you can add the CODEOWNERS.destination_branch_pattern followed by a branch pattern
# to your CODEOWNERS file. This file is then only active for pull requests with matching destination branch.
# For example if you want code owners to be active only for the branch master, add
CODEOWNERS.destination_branch_pattern master
# And if you also want to protect release branches, just add another line with a pattern like
CODEOWNERS.destination_branch_pattern release/*
# For supported pattern format, please check https://confluence.atlassian.com/bitbucketserver070/branch-permission-patterns-996644139.html .

# Enables subdirectories overrides, where a CODEOWNERS file in a subdirectory overrides all settings
# Ideal when you have independent projects in subdirectories which require independent rules
# By default this is disabled and only the CODEOWNERS at the top of the repository is used
# CODEOWNERS.toplevel.subdirectory_overrides enable

# Suppress info comment on pull request creation about added code owners. Info comment will be added by default.
# CODEOWNERS.toplevel.create_pull_request_comment disable

# Every rule line is a file pattern that is followed by one or more code owners.

# This user will be the default owner for everything in the repo.
*                        @PeterTheHacker

# Ordering is important! The last matching file pattern has the highest precedence.
# So if only a Java file is in the pull request, PeterTheJavaExpert is the code owner
# and not the default owner PeterTheHacker.
*.java                   @PeterTheJavaExpert

# You can also use Bitbucket groups which start with '@@' compared to single users.
# This will add all members of the Bitbucket group JSExperts.
*.js                     @PaulTheJSGuru @@JSExperts

# If you want, you can define your own code owner groups instead of using Bitbucket groups.
# This will define a new group MyDevs, both including users and other groups:
@@@MyDevs                @PeterTheHacker  @PeterTheJavaExpert ann@scala.lang @@JSDevs

# For Bitbucket users and groups with spaces in their name, put them into double quotes.
*.ts                     @"Paul the JSGuru" @@"Dev Ops Team"

# You can also specify code owners by email address if you prefer:
docs/*                   docs@example.com

# When your glob expression contains spaces, put the glob into double quotes.
"a/path with spaces/*"   docs@example.com

# AnnTheScalaPro is the code owner of all files in the /src/main/scala directory at
# the root and all its descendants (e.g., /src/main/scala/com/x/y/z.scala).
/src/main/scala/         @AnnTheScalaPro

# ci/* will match all files in the directory ci, but not deeper in
# the directory hierarchy (so ci/jobs/prod.yml will not match).
ci/*                     @devops

# You can use '!' for negation in front of file pattern without any code owners afterwards,
# to unset all previously defined code owners of the files.
# e.g. devops group wants to review everything under ci (as defined above),
# except ci/playgrounds.yml, which nobody needs to review:
!ci/playgrounds.yml

# It's also possible to use double-asterisk globs. Here's an example that will match
# all JS files under /src/components.
src/components/**/*.js   @@MyDevs

# GroovyMaster owns any files in the groovy directory anywhere in the
# file tree (e.g., src/main/groovy/com/x/y/z.groovy).
groovy/                  @GroovyMaster

# Files starting with a `#` or a `!` can still be used by escaping them.
\#myfile.rb              @PeterTheHacker
\!yourfile.rb            @PaulTheJSGuru

# It is important to protect CODEOWNERS file as well because otherwise it can get deleted
# or moved within a pull request; so we want to assign a code owner to it which can prevent this
CODEOWNERS               @CTO