Setting up CODEOWNERS: Ending Stale PRs and Incorrect Reviewers

The Pain of Abandoned PRs or Misaligned Reviews

If you’re working in a team of 5-10 people, you’ve likely experienced this: creating a Pull Request (PR) with great effort only to have it sit there unnoticed. You send the link to a group chat, wait an hour, two hours, and then an entire day passes in silence. Or worse, a Frontend specialist reviews Backend logic, leading to feedback that isn’t quite on point.

The root of the problem is ambiguity in “Code Ownership.” When everyone has the right to review everything, the result is often that no one feels responsible for doing it. The consequence? Release speed slows down, and code quality becomes a matter of luck.

A real-world experience from an outsourcing project I worked on: A Junior developer accidentally modified the docker-compose.yml file belonging to the DevOps team. Due to a lack of safeguards, the PR was approved by another Junior and merged directly into the main branch. The result was a CI/CD crash, and the whole team wasted an entire afternoon tracing the error. After that incident, I realized CODEOWNERS isn’t just an option—it’s a necessity for system protection.

What is CODEOWNERS?

Think of CODEOWNERS as a “role assignment” within the repository. It is a simple configuration file in the repo (GitHub/GitLab) that defines exactly which individual or team is responsible for specific parts of the code.

As soon as you modify a file listed in the file, the system automatically assigns those individuals as Reviewers. You no longer need to remember who wrote which file or manually tag names as before.

The three most practical benefits include:

• Full Automation: Save about 5-10 minutes of waiting and tagging for every PR.
• Right Person, Right Task: Database code is reviewed by the DBA, while CSS is handled by the UI/UX expert.
• Maximum Security: Sensitive files like /security or /config are always monitored by the most experienced members.

Detailed Guide to Setting Up CODEOWNERS

Both GitHub and GitLab support this file with similar syntax, differing only slightly in where the file is placed.

1. File Location

You can place the CODEOWNERS file (without an extension) in the following paths:

• Root directory: /CODEOWNERS
• Hidden directory: .github/CODEOWNERS or .gitlab/CODEOWNERS

I always prefer placing it in the .github/ or .gitlab/ directory. This keeps the project’s root directory cleaner.

2. File Syntax

The syntax of CODEOWNERS is very similar to .gitignore. You just need to specify the file path, followed by the username of the person responsible.

# Default assignment for all files in the repo
*       @tech-lead-username

# Frontend team is responsible for all .js files
*.js    @org-name/frontend-team

# Specifically assign a documentation directory
/docs/  @documentation-expert

# Infrastructure config files only DevOps can review
/infra/terraform/  @devops-senior

Golden Rule: The order in the file is extremely important. Lines at the bottom have the highest priority (overriding previous rules).

Real-world Application for a Fullstack Project

Suppose your team is running a Web application. To avoid a “anyone can edit anything” situation, the CODEOWNERS file should be broken down as follows:

# 1. Tech Lead oversees the entire system
* @big-boss

# 2. Permissions for Backend
/src/api/ @backend-team

# 3. Permissions for Frontend
/src/components/ @frontend-team
/src/styles/ @frontend-team

# 4. Protect infrastructure and CI/CD
.github/workflows/ @devops-engineer
Dockerfile @devops-engineer

When a Frontend developer edits a file in /src/components/, GitHub will automatically assign the @frontend-team to the PR. If they “happen” to edit the Dockerfile as well, the @devops-engineer will be notified by the system immediately.

Combining with Protected Branches to Increase Discipline

If you only create the CODEOWNERS file, it remains just a suggestion. To turn it into a real barrier, you need to enable Branch Protection Rules.

On GitHub, go to Settings > Branches, select the main branch, and check Require review from Code Owners. Once enabled, a PR cannot be merged without a signature from the designated “owner.” Even if you receive dozens of approvals from others, the system will block it until the authorized person agrees.

Hard-learned Lessons

During the implementation process for many projects, I’ve drawn three lessons to avoid causing trouble for the team:

• Avoid too many owners for a single file: If five people manage a file, the “someone else probably reviewed it” mentality kicks in. It’s best to assign it to 1-2 people or a small team.
• Update personnel promptly: Update the CODEOWNERS file as soon as someone leaves. Don’t let a PR get stuck just because the only reviewer left the company last month.
• Don’t turn the Tech Lead into a bottleneck: Avoid assigning * @tech-lead to every file in a large team. The Tech Lead will be flooded with notifications and become the project’s bottleneck.

Applying CODEOWNERS is a vital step toward professionalizing your workflow. It’s not just a tool; it helps shape a culture of responsibility within the team. Try setting it up today—you’ll see the difference in speed and code quality in just a week.