Demo Branch Protection

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.

The image shows a GitHub repository settings page, specifically for configuring branch rules. It includes options for setting rulesets, enforcement status, bypass lists, and branch targeting criteria.

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

The image shows a GitHub repository settings page with options for merging methods, blocking force pushes, and requiring code scanning results and Copilot code review.

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.

The image shows a GitHub repository settings page, specifically under "Rulesets" for a repository named "block-buster," with an active ruleset named "prod-rules." The bypass list is empty, and the settings indicate it applies to the "main" branch.

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:

# 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:

// ==== 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.

This image shows a GitHub interface for creating a pull request, with options to add a title, description, and reviewers. The title field is populated with "Update script.js."

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.

The image shows a GitHub pull request page for updating the script.js file in a repository. It indicates the request is open, awaiting review, and requires at least one approving review to merge.

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

Watch Video

Repository Privacy Setting Options

Main Features and Options in Security Tab

Introduction

Git and GitHub Basics

GitHub Entities

GitHub Markdown

GitHub Desktop

GitHub Mobile

GitHub Repositories

Issues

Pull Requests

Discussions

Notifications

Gists, Wikis, and GitHub Pages

GitHub Actions

GitHub Copilot

GitHub Codespaces

Manage Your Work with GitHub Projects

Authentication and Security

GitHub Administration

Benefits of Open-Source Community

Benefits of Open Source – Applications

Demo Branch Protection

Open the repository and locate branch protection

Create a ruleset and configure enforcement

Common protection options

Code scanning and integrations

How protection affects everyday workflows

Required checks and merging

Links and references

Watch Video

​Open the repository and locate branch protection

​Create a ruleset and configure enforcement

​Common protection options

​Code scanning and integrations

​How protection affects everyday workflows

​Required checks and merging

​Links and references

Watch Video

Open the repository and locate branch protection

Create a ruleset and configure enforcement

Common protection options

Code scanning and integrations

How protection affects everyday workflows

Required checks and merging

Links and references