1. Using Visual Builder Studio
  2. Common Tasks
  3. Manage Source Code Files with Git
  4. Review Source Code with Merge Requests
  5. Merge Request and Branch Administration
  6. Assign Owners to Files in the Project's Git Repository

Assign Owners to Files in the Project's Git Repository

If you have administrative or project owner permissions, you can define individual users or groups that are responsible for code in a repository. You designate file ownership by creating a new file called CODEOWNERS in the root 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. You can assign different code owners for different branches, as needed.

There are several reasons why you would want to use a CODEOWNERS file. This file is meant to be a centralized place to give credit and ownership for chunks of the codebase. Having this paper trail can be helpful when new employees are hired and brought onto the project, and can even streamline the resolution of questions that come up during the course of development since you know who to ask. If you define file owners, you can alert those owners when the code they are responsible for has been changed or automatically include the file owner in code reviews and/or merge requests.

Code owners must have write permissions for the repository. When the code owner is a group, that group must have write permissions, even if all the individual members of the group already have write permissions directly, through organization membership, or through another group membership.

Repository owners can add branch protection rules to ensure that changed code is reviewed by the owners of the changed files. In other words, when someone enables required reviews, they can also require approval from a code owner before the author can merge a request in the repository. See (Set Review and Merge Restrictions on a Repository Branch). If a file has a code owner, you can see who the code owner is before you open a merge request. In the repository, you can browse to the file and hover over the Show Code Owner icon, which will display its owner. You can also click the icon and go to the line in the CODEOWNERS file that assigns ownership for that file.

You can reduce the size of your CODEOWNERS file by using wildcard patterns to consolidate multiple entries into a single entry.

Syntax:

A CODEOWNERS file uses a pattern that follows most of the rules used in gitignore files. See Git's gitignore Documentation.

Note:

These syntax rules for gitignore files do not work in CODEOWNERS files:

  • Escaping a pattern starting with # using \ so it is treated as a pattern, not a comment
  • Using ! to negate a pattern
  • Using [ ] to define a range of characters
The pattern is followed by one or more usernames or group names using the standard @username or @group-name format.

CODEOWNERS paths are case sensitive, so even case insensitive systems, like macOS, must use paths and files that are cased correctly in the CODEOWNERS file.

If any line in your CODEOWNERS file contains invalid syntax, that line will be skipped.

Example

Here's a sample CODEOWNERS file:

# Each line is a file pattern followed by one or more owners.

/a/ @alex.admin

*.txt @alex.admin @don.developer

pom.xml @Group1 @users1 @testers2 @developers1

cc/ clara.coder@example.com

/docs/f[0-9]*.txt @alex.admin
In this example:
  • alex.admin owns the "a" subfolder and everything in it
  • alex.admin and don.developer own all the .txt files in the project's Git repository
  • Groups (Group1, users1, testers2, and developers1) can own files, like the pom.xml file listed here
  • clara.coder@example.com owns all the files under the "cc" directory
  • alex.admin owns all files under the docs directory and its subfolders that start with "f", contain some number in the folder name, and have a "txt" file extension

See Example of a CODEOWNERS file for another more detailed example.