Enforce Protected Main Branch and Prevent Direct Commits

Description

This rule enforces that all production-level code must be committed to the main branch through a protected pull-request workflow. It explicitly disallows direct commits or forced pushes to the main branch, ensuring traceability, auditability, and protection against bypassing peer-review and automation gates.

Purpose

To maintain integrity and transparency of production code by requiring a formal pull-request and review process. This reduces human error, enforces team-based validation, and aligns with regulatory expectations for traceable software development lifecycles (SDLC).

Scope

• •All production repositories (Java, Kotlin, Python, JavaScript, TypeScript)
• •All main branches or equivalent (e.g., main, master, prod)
• •CI/CD pipeline enforcement in GitHub, GitLab, Bitbucket
• •DevOps, Engineering, and Release Management teams

SDLC Integration

• •Planning: Defines deployment constraints and commit protocols
• •Analysis: Ensures auditability of change origins
• •Design: Preserves architectural control via PR review
• •Development: Prohibits accidental force-push or direct merge
• •Testing: Enforces merge gates pre-deployment
• •Deployment: Assumes protected branches are trusted sources
• •Maintenance: Prevents hotfix chaos and untraceable patching

Standards

Access Control & CI/CD Protection

• •All production code MUST be committed to a protected main branch via pull-request
• •Developers MUST NOT directly push or force-push to main
• •All repositories MUST have branch protection rules in place with required PR review
• •CI pipeline MUST reject direct commits on protected branches

Actionable Metrics

Implementation

Configuration Requirements

• •Enable branch protection in GitHub:
  • •Require PR review before merging
  • •Restrict push access
  • •Require status checks to pass

Example: Correct Implementation

# Pushes to feature branch
git checkout -b feature/refactor-invoice
git push origin feature/refactor-invoice
# Submit PR to main

Approved Exceptions

The following automated workflows are approved exceptions to the direct push restriction on the main branch:

Automated Release Workflows

Purpose: CI/CD release workflows may push version updates directly to main to maintain atomic release operations (tagging and versioning in a single transaction).

Requirements:

• •MUST be limited to automated CI/CD workflows authenticated via GitHub Actions with GITHUB_TOKEN
• •MUST only update version metadata files (e.g., VERSION, package.json, pom.xml)
• •MUST include [skip ci] or equivalent tag in commit messages to prevent infinite workflow loops
• •MUST be preceded by validation checks (e.g., linting, and where applicable, testing and security scans)
• •MUST NOT modify source code or functional logic

Example: The trigger_release.yml workflow:

1. •Runs linting checks to validate all skills
2. •On manual release trigger, updates VERSION file
3. •Commits with [skip ci] tag
4. •Creates and pushes release tag
5. •Generates GitHub Release

This exception is justified because:

• •Release operations require atomic version updates and tagging
• •The workflow is human-initiated (workflow_dispatch) and manually triggered
• •All code changes still require PR review before the release workflow runs
• •Version file updates are non-functional and fully auditable

Enforcement: Branch protection rules SHOULD allow the GitHub Actions bot account to bypass push restrictions for release workflows only.