> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Repository Privacy Setting Options > Guidance on repository governance using branch protection, CODEOWNERS, and required reviewers to enforce reviews, ownership, and CI gating for stable auditable main branches Move a repository from a personal or generic workflow to a production-ready, team-governed environment by applying three governance pillars that ensure every change is verified before reaching protected branches. These pillars enforce review, ownership, and CI gating so your main or production branches stay stable and auditable. * Branch protection * CODEOWNERS * Required reviewers ## At-a-glance: governance pillars | Pillar | Purpose | Key benefit | | ------------------ | ---------------------------------------------------- | ----------------------------------------------------------------------------- | | Branch protection | Enforce merge and push policies on critical branches | Prevents direct or force pushes; ensures merges follow team processes | | CODEOWNERS | Map files and paths to responsible users or teams | Automatically requests reviews from designated owners when those files change | | Required reviewers | Make code review a blocking requirement for merges | Ensures peer review, knowledge sharing, and prevents unilateral deployments | ## 1) Branch protection Branch protection rules are immutable guardrails you apply to important branches (for example, `main` or `production`). They convert ad-hoc Git operations into policy-driven workflows: merges must follow rules, CI must pass, and direct pushes or force pushes can be blocked. Typical branch protection features include required status checks, required approving reviews, and restrictions on who can push or merge. Benefits: * Enforce a pull-request-only workflow * Prevent accidental overwrites or bypassing CI/CD * Require specific checks and approvals before merge ## 2) CODEOWNERS A `CODEOWNERS` file maps file paths to users or teams so that GitHub automatically requests reviews from the right people when code touching those paths is changed. Place it at `.github/CODEOWNERS`, the repository root, or in the `.github` folder in the repository. The image is a table comparing two features, "Branch Protections" and "CODEOWNERS," detailing their technical purposes and key benefits. It highlights how branch protections prevent accidental actions on stable code, and CODEOWNERS automates reviewer assignment based on file modifications. A simple `CODEOWNERS` example: ```text theme={null} # All files under /docs/ are owned by the docs team /docs/ @my-org/docs-team # All Python files anywhere are owned by the python team *.py @my-org/python-team # A specific file owned by an individual /scripts/deploy.sh @alice ``` Why `CODEOWNERS` matters: * Reduces reviewer fatigue by routing reviews to the right experts * Ensures specialized areas (security, infra, APIs) always receive appropriate oversight * Integrates with branch protection to require owners’ approvals automatically ## 3) Required reviewers Requiring reviewers makes code review a blocking policy: a pull request cannot be merged until the required approvals are provided. This helps share knowledge across the team and prevents a single developer from bypassing review controls. Branch protection rules can be configured to: * Require one or more approving reviews * Dismiss stale reviews when new commits are pushed * Enforce that reviews come from `CODEOWNERS` when enabled The image is a table describing features related to code management: Branch Protections, CODEOWNERS, and Required Reviewers, each with its technical purpose and key benefits. Enable "Require pull request reviews before merging" and, if you use CODEOWNERS, also enable "Require review from Code Owners" in branch protection rules to ensure owners are automatically requested and their approvals enforced. ## Recommended branch protection settings | Setting | Purpose | | --------------------------------------------- | ---------------------------------------------------------- | | Require pull requests before merging | Prevents direct pushes and forces merges to go through PRs | | Require status checks to pass | Gate merges on CI/CD and other automated checks | | Require a minimum number of approving reviews | Ensure multiple eyes on changes | | Require review from CODEOWNERS | Force owner approvals for designated file areas | | Dismiss stale pull request approvals | Require re-review after new commits are added | | Restrict who can push or merge | Limit merge rights to specific users or teams | | Lock the branch | Prevent deletion and block force pushes | Applying these governance controls ensures that changes are reviewed, tested, and auditable before reaching production branches. Combined, branch protections, CODEOWNERS, and required reviewers create a "trust but verify" culture that enables teams to move quickly while maintaining code quality and an auditable history. ## Links and references * [Protecting branches - GitHub Docs](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/about-protected-branches) * [CODEOWNERS - GitHub Docs](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) * [Pull request reviews - GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests)