Loading page
About this tool
Build a CODEOWNERS file with path patterns and team handles, validate owners, and preview which rule wins for any file path.
The CODEOWNERS File Generator builds a CODEOWNERS file — the file GitHub, GitLab and Bitbucket use to auto-request reviewers when matching files change — from path patterns and owner handles. It validates each owner as @username, @org/team or an email, applies the gitignore-style pattern rules from GitHub's documentation (minus the unsupported ! negation and [..] ranges), and includes a live match preview showing which rule wins for any file path, since the last matching rule takes precedence.
Open CODEOWNERS File Generator on AltFTool — it loads instantly in your browser.
Set the 'Default owner for everything (optional)' field — written first as * so every later rule overrides it — and add rows under 'Rules (pattern → owners) — order matters', using the 'Add rule' button for more.
Type any file path into 'Match preview — who owns this path?' to see the winning rule under GitHub's last-match precedence, shown as 'Owned by … — winning rule: …'.
Read the generated file in the CODEOWNERS pane and click 'Copy file' to copy it; owners that are not @username, @org/team or an email are rejected before you export.
Type any path and see exactly which rule wins — the subtlety that breaks most hand-written files.
Rejects handles that are not @username, @org/team or an email before GitHub silently ignores them.
Enforces GitHub's documented limits: no ! negation, no [..] character ranges.
In the repository's root, the .github/ directory, or docs/ — on the branch being targeted; GitHub uses the copy on the base branch of each pull request. If files exist in more than one location, the .github/ copy wins, then root, then docs/.
The last matching pattern in the file takes precedence — order matters, unlike gitignore where more specific rules do not simply win by position for ownership. That is why a catch-all * rule must be the first line: every later, more specific rule then overrides it for its paths.
GitHub accepts @username, @org/team-name, or an email address associated with a GitHub account. Users must have write access to the repository, and teams must have explicit write access — otherwise the entry is silently ignored and no review is requested.
Almost. The same wildcard rules apply — * (not crossing /), ** (crossing directories), ?, root-anchoring with a leading or embedded slash — but GitHub's docs state two exceptions: you cannot negate a pattern with ! and you cannot use character ranges like [0-9]. A trailing slash matches everything inside the directory.