Skip to main content
Developer Documentation / Project Tools

CODEOWNERS Generator

Build a valid GitHub or GitLab CODEOWNERS file from simple path and owner rules, with owner syntax checks.

List which people or teams own which paths, and get a correctly formatted CODEOWNERS file that requests the right reviewers on every pull request.

Add:
Owners can be @username, @org/team-name or an email address. Later rules win when several patterns match a file, so put general rules first and specific ones last.

Owners need write access to the repository for review requests to work - check that after adding the file.

What Is the CODEOWNERS Generator?

A CODEOWNERS file tells GitHub and GitLab who is responsible for which files. When a pull request changes a file, the platform automatically requests a review from its owners, and branch protection can require their approval. This tool turns a simple list of pattern owner lines into a correctly formatted file and checks the owner syntax as it goes.

When to Use It

  • Setting up review rules for a repository shared by several teams.
  • Making sure infrastructure, CI workflows or security-sensitive folders always get a review from the right people.
  • Cleaning up an existing CODEOWNERS file that has grown hard to read.

How to Use It

  1. Optionally enter default owners - they own every file not matched by a later rule.
  2. Write one rule per line, or use the preset buttons to add common ones.
  3. Choose GitHub or GitLab and click Generate CODEOWNERS.

Example

The line /api/ @my-org/backend alice@example.com makes the backend team and Alice owners of everything under /api/. A rule *.js @frontend-dev covers JavaScript files anywhere in the repository.

Understanding the Output

Patterns are aligned into a column so the file is easy to scan. The last matching rule wins, so general rules go first and specific ones last. Warnings flag owners that are not a valid @user, @org/team or email, lines with no owner, and negated patterns (!), which CODEOWNERS does not support.

Limitations

The tool checks syntax only - it cannot see whether a user or team exists or has write access, which is required for review requests to work. GitLab [Section] headers are passed through for GitLab files. To go with it, the CONTRIBUTING.md Generator explains the review process to contributors and the .gitignore Generator keeps build output out of the repository.

Frequently Asked Questions

On GitHub, use .github/CODEOWNERS, the repository root or docs/CODEOWNERS; GitHub reads the first one it finds in that order. On GitLab, use CODEOWNERS in the root, .gitlab/ or docs/. The file must be on the branch that pull requests target.

The last matching line in the file wins, and only its owners are requested. Put broad rules such as * near the top and more specific paths further down.

The user or team must have write access to the repository, and a team must be visible. Also check the file has no syntax errors - GitHub shows them when you open the CODEOWNERS file in the web interface.

No. Unlike .gitignore, CODEOWNERS does not support negated patterns. To leave a path without owners, add a later rule for that path with no owner listed.
Share this tool: