
When working in a team, controlling who reviews, approves, and merges code is just as important as writing good code. GitHub’s CODEOWNERS file, repository permissions, and teams (groups) provide a structured way to enforce accountability and maintain code quality.
In this post, we’ll explore:
- What a CODEOWNERS file is
- How to set it up
- How permissions work
- Managing teams (groups) and adding users
- Best practices for collaboration and security
1. What is a CODEOWNERS File?
A CODEOWNERS file defines who owns specific parts of a codebase.
When someone makes changes to those files, GitHub automatically requests reviews from the assigned owners.
Why it matters:
- Ensures subject-matter experts review relevant changes
- Reduces risk of unreviewed or low-quality code getting merged
- Improves accountability and knowledge-sharing
2. Creating a CODEOWNERS File
The file must be named CODEOWNERS (no extension) and placed in one of the following locations:
.github/CODEOWNERSdocs/CODEOWNERS- Root of the repository
Example CODEOWNERS file:
# Global owners for entire repo
* @team-leads
# Assign owners for frontend code
/frontend/ @frontend-devs
# Assign owners for backend code
/backend/ @backend-devs
# Assign owner for a specific file
README.md @project-manager
3. How CODEOWNERS Works
- When a pull request modifies files, GitHub automatically adds the corresponding owners as required reviewers.
- You can assign individuals (
@username) or teams (@org/team-name). - Multiple owners can be listed — any of them can approve the changes.
4. Enforcing CODEOWNERS with Branch Protection
By default, CODEOWNERS suggests reviewers but doesn’t enforce rules.
To enforce approvals:
- Go to Repo Settings → Branches → Branch Protection Rules
- Protect
main(or relevant branch) - Enable:
- ✅ Require pull request reviews before merging
- ✅ Require review from Code Owners
This ensures no code touching owned files is merged without proper approval.
5. Permissions in GitHub
GitHub permissions control what collaborators can do in a repository.
Roles and Access Levels:
| Role | Permissions |
|---|---|
| Read | View repo, clone, open issues, comment |
| Triage | Manage issues and PRs, but no code push |
| Write | Push commits, create branches, open PRs |
| Maintain | Manage settings, labels, branches, repo configs |
| Admin | Full access, including repo deletion and settings |
💡 Best practice: Grant least privilege necessary. For example, most developers only need write, while leads can have maintain or admin.
6. Teams (Groups) in GitHub
GitHub lets you organize users into teams (also called groups).
Teams make it easier to:
- Assign permissions to multiple users at once
- Use team handles in
CODEOWNERS - Structure access by department or expertise
Example:
@org/frontend-devs→ frontend team@org/backend-devs→ backend team@org/devops→ CI/CD and infrastructure
7. Adding Users to Teams (Groups)
- Go to your GitHub Organization
- Navigate to Teams
- Select or create a new team (
frontend-devs) - Click Add a member → Search and add a GitHub username
- Assign roles within the team (e.g., member, maintainer)
💡 You can also nest teams for hierarchical structures. Example:
@org/engineering(parent team)@org/frontend-devs@org/backend-devs
8. Best Practices for CODEOWNERS, Permissions, and Teams
✅ Use teams instead of individuals – avoids bottlenecks if someone is unavailable.
✅ Organize teams by expertise – frontend, backend, QA, DevOps.
✅ Regularly review team membership – remove inactive users.
✅ Limit admin rights – only leads and project managers should have admin access.
✅ Require CODEOWNER approvals – enforce this with branch protection.
✅ Avoid too many code owners per file – keeps responsibility clear.
✅ Restrict direct pushes to main – all changes should flow through PRs.
9. Example Workflow with CODEOWNERS + Teams + Permissions
- A developer modifies
frontend/App.js. - GitHub automatically requests review from
@org/frontend-devs. - Branch protection requires at least one approval from code owners.
- Only developers with
writepermission can push to branches, and merges need approval. - Admins and maintainers manage settings but don’t bypass reviews.
Conclusion
By combining CODEOWNERS, permissions, and teams (groups), you can:
- Ensure the right experts review the right code
- Control repository access with least-privilege principles
- Maintain a clear and scalable collaboration workflow
In short: Define ownership, enforce approvals, and manage access with teams. This guarantees code quality, accountability, and smoother collaboration across your organization.
You Might Also Like
- 👉 Day 1: Git Fundamentals
- 👉 Day 2: Basic Git Workflow
- 👉 Day 3: Branching and Merging
- 👉 Day 4: Remote Repositories
- 👉 Day 5: Advanced Git Operations
- 👉 Day 6: Git Workflows and Best Practices
- 👉 Day 7: Troubleshooting and Expert Techniques
- 👉 Advanced Git Commands You Need to Master (With Examples)
- 👉 Git Best Practices for Branching and Approvals
🛠️ Recommended Tools for Developers & Tech Pros
Save time, boost productivity, and work smarter with these AI-powered tools I personally use and recommend:
1️⃣ CopyOwl.ai – Research & Write Smarter
Write fully referenced reports, essays, or blogs in one click.
✅ 97% satisfaction • ✅ 10+ hrs saved/week • ✅ Academic citations
2️⃣ LoopCV.pro – Build a Job-Winning Resume
Create beautiful, ATS-friendly resumes in seconds — perfect for tech roles.
✅ One-click templates • ✅ PDF/DOCX export • ✅ Interview-boosting design
3️⃣ Speechify – Listen to Any Text
Turn articles, docs, or PDFs into natural-sounding audio — even while coding.
✅ 1,000+ voices • ✅ Works on all platforms • ✅ Used by 50M+ people