> ## 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.
# Demo Branch Protection
> Guide demonstrating how to create and enforce GitHub branch protection rules requiring pull requests, code reviews, status checks, and preventing direct commits to critical branches like main
Branch protection rules prevent accidental or unauthorized direct pushes to critical branches (for example, `main`). They enforce workflows such as requiring pull requests, code reviews, and passing automated checks before changes can be merged. This guide walks through creating a branch ruleset, targeting branches, selecting protection settings, and observing how GitHub blocks direct commits and enforces pull-request workflows.
## Open the repository and locate branch protection
Open the repository you want to protect — in this demo it’s the Block Buster repository. If the default branch is unprotected, GitHub may show a banner offering a quick “Protect this branch” action. Alternatively, configure comprehensive rulesets by navigating to Settings > Branches in the repository.
## Create a ruleset and configure enforcement
Create a new ruleset (for example, name it `prod-rules`) and enable enforcement. You can optionally add a bypass list to exempt specific users or teams (such as a small set of emergency admins). In this demo, we intentionally leave the bypass list empty so the rules apply to everyone, including repository admins.
Leaving the bypass list empty means no one—regardless of permissions—can bypass the rules. This is a strict setting useful for high-stakes repositories.
Target which branches the ruleset should affect. You can use explicit names (e.g., `main`) or wildcard patterns (for example, `release/*` or `feature/*`). Any branch matching the pattern will be subject to the rules; in this demo we target the default branch `main`.
### Common protection options
Below are commonly used protection settings and when to enable them.
| Protection option | Purpose | Example / Notes |
| ------------------------------------- | --------------------------------------------------------- | ---------------------------------------------------- |
| Require a pull request before merging | Disallows direct commits to protected branches | Ensures every change is reviewed and merged via PR |
| Require approving reviews | Enforces code review by one or more reviewers | Example: set minimum approving reviews to `1` or `2` |
| Require CODEOWNERS approval | Requests review from maintainers listed in `CODEOWNERS` | See [CODEOWNERS](/) for format and behavior |
| Restrict merge methods | Limits allowed merge strategies (merge, squash, rebase) | Prevents undesirable histories or merges |
| Require status checks to pass | Blocks merges until CI, static analysis, or scans succeed | Example: CodeQL or other CI workflows |
| Block force pushes / deletion | Prevents destructive changes to branch history | Recommended for protected release branches |
## Code scanning and integrations
GitHub Code Scanning (CodeQL) is a common built-in security scanner. When enabled, CodeQL runs as a GitHub Actions workflow and can be configured to mark PRs with alerts. You can require that these scans succeed (or meet a configured severity threshold) before allowing merges.
Create the ruleset. GitHub may prompt you to re-authenticate or complete two-factor authentication (2FA) if your account policy or organization requires it.
If your organization enforces two-factor authentication or SSO, you may be prompted to verify your identity before activating the ruleset.
When the ruleset is saved and activated you’ll see it listed under the repository rulesets.
## How protection affects everyday workflows
Once the ruleset is active, direct commits to `main` are blocked. For example, editing the README and attempting to commit directly to `main` will not succeed; GitHub will prompt to create a new branch and initiate a pull request instead.
Example README content that might be edited:
```markdown theme={null}
# block-buster
An enhanced version of the Block Buster Brick Breaker game with advanced features
```
When you try to commit to the protected `main` branch, GitHub prevents the direct commit and offers to create a new branch with your changes and open a pull request. Because the bypass list was left empty, even repository administrators must follow the same PR-based workflow.
If you proceed by creating a branch and editing a source file (for example adding a line to `script.js`), the changes will be committed to the new branch and a pull request will be created.
Example change in `script.js`:
```javascript theme={null}
// ==== GAME STATE ====
const gameState = {
currentLevel: 1,
score: 0,
highScore: localStorage.getItem('blockBusterHighScore') || 0,
lives: 3,
isPaused: false,
isGameRunning: false,
balls: [],
particles: [],
bullets: [],
activePowerups: [],
powerups: {
multiBall: { active: false, activationTime: 0 },
megaPaddle: { active: false, activationTime: 0 },
bulletMode: { active: false, activationTime: 0 }
},
bulletFireCounter: 0
};
const canvas = document.getElementById('gameCanvas');
const ctx = canvas.getContext('2d');
let paddle = {
x: (canvas.width - 100) / 2,
y: canvas.height - 25
};
```
When you push the branch, GitHub will pre-fill the pull request title and description based on your commit and branch name.
If a `CODEOWNERS` file is present, GitHub automatically requests reviews from the listed code owners (in this demo, Alice is assigned). The PR UI will clearly indicate required reviews and any other merge prerequisites.
## Required checks and merging
Required status checks—such as CI builds, linters, or CodeQL scans—run automatically as part of the PR. The pull request cannot be merged until both of the following conditions are met:
* The configured minimum number of approving reviews have been provided.
* All required status checks (for example, code scanning workflows) have completed and passed or otherwise met the configured criteria.
Once those conditions are satisfied, the merge button becomes available. Changes will be merged using whichever merge methods you allowed in the ruleset (merge, squash, or rebase).
## Links and references
* [Branch protection rules — GitHub Docs](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches)
* [CODEOWNERS — GitHub Docs](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)
* [CodeQL — GitHub Docs](https://docs.github.com/en/code-security/code-scanning/using-code-scanning-with-codeql/about-code-scanning-with-codeql)
* [GitHub Actions — GitHub Docs](https://docs.github.com/en/actions)