Learn Semantic Release - Protected Branches & PR Policies

#Introduction

In episode 12 we discussed workflow security, from least privilege to secret protection. Now consider a reality: once releases run automatically, one bad commit on main immediately becomes a released production version. This is where branch protection becomes the last line of defense before code touches a release.

Branch protection rules are a gate that forces every change through a PR, status checks, and review before it lands on important branches. For a semantic-release pipeline, this isn't just good practice — it's an absolute requirement so automation doesn't backfire.

#Why main and rc Must Be Protected

The two most sensitive branches in our repository:

• main — the source of stable releases; every merge here can produce a new 1.2.3 version.
• staging (aka rc) — the source of release candidate 1.2.3-rc.N tested in the staging environment.

Because both branches trigger automatic releases, they must be governed by the strictest rules. feature/* branches can be looser — a green pipeline is enough — but main and rc must pass every gate.

#Branch Protection Walkthrough in GitHub

The steps go through the GitHub interface:

1. Open Settings → Branches → Add branch protection rule.
2. Fill in Branch name pattern with main.
3. Check Require a pull request before merging and set Required number of approvals to e.g. 1–2.
4. Check Require status checks to pass before merging.
5. Check Require branches to be up to date before merging so status checks run against the latest commit.
6. Repeat for the staging pattern.

For teams that want to apply the same rules across repositories, GitHub also offers rulesets (Settings → Rules → Rulesets) that can be managed centrally and support code-based configuration.

#Require Status Checks: Lint, Build, Dry Run

Status checks on GitHub come from the job names in the CI workflow that runs on pull requests. Those are the names you check off in the required status checks list:

name: CI
 
on:
  pull_request:
    branches: [main, staging]
 
permissions:
  contents: read
 
jobs:
  lint:
    name: Lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - run: bun run lint
 
  build:
    name: Build
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - run: bun run build
 
  dry-run:
    name: Dry Run
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - run: npx semantic-release --dry-run --no-ci

In the branch protection form, check Lint, Build, and Dry Run as required checks. The presence of the Dry Run check is crucial: it validates that the commits in that PR would produce the correct version, a valid changelog, and no configuration errors — without actually releasing anything. You can try the same command locally with npx semantic-release --dry-run --no-ci.

#Mandatory Reviewers

Besides the automatic pipeline, human review stays mandatory. Set up:

• Require a pull request before merging — forces every change through a PR.
• Required number of approvals — a minimum of 1 reviewer for small PRs, 2 for sensitive code.
• Require review from Code Owners — if a CODEOWNERS file exists, changes to certain parts automatically assign reviewers.
• Dismiss stale reviews — old reviews are automatically dismissed when a new commit lands.

#Enforcing Rules via Code

Branch protection can also be applied reproducibly with the GitHub CLI using a JSON file as input:

{
  "required_status_checks": {
    "strict": true,
    "contexts": ["Lint", "Build", "Dry Run"]
  },
  "required_pull_request_reviews": {
    "required_approving_review_count": 1
  },
  "enforce_admins": true
}

gh api repos/devnull/learn-semantic-release/branches/main/protection \
  --method PUT \
  --input protection.json

This approach makes security configuration reviewable like ordinary code and reusable across other repositories.

#Merge Strategy and Its Impact on Conventional Commits

How a PR is merged determines the shape of the history semantic-release reads. The three main options on GitHub's merge button:

Conversely, merge commit preserves the original per-commit messages so the analysis is more accurate, but it carries a risk: if the commits inside aren't consistent, the version can bump more than once for a single PR. Many teams combine squash-merge with a "PR title must be valid" rule to get both clean history and predictable analysis.

To enforce this policy at the repository level, configure Settings → Allow merge commits / Allow squash merging / Allow rebase merging and turn off the options you don't want.

#Conclusion

Episode 13 recap:

• Protect main and staging (rc) with strict branch protection rules.
• Require the Lint, Build, and Dry Run status checks — job names must stay in sync.
• Mandatory reviewers with an approval count and stale review dismissal.
• Choose the right merge strategy: squash-merge needs a valid PR title, merge commit preserves per-commit detail.
• Branch protection and rulesets can also be applied centrally and code-based.

With strong gates, every release that ships is tested in two layers: automatic and human. In the next episode we'll discuss Audit, Changelog & Release Notes — how semantic-release writes the changelog automatically and links it to GitHub Releases. See you there!