Q: Design a branch-protection and merge-policy setup for a regulated environment (PCI / SOC 2) with 30 services in a monorepo. Walk me through the controls you'd put on `main` and how they interact with developer ergonomics.

Compliance auditors essentially want to see: every change to main is reviewed by someone other than the author, every change is traced to a ticket, every change runs the same controls, and the history is tamper-evident.

• No direct pushes — pushes only via PR. Restrict who can push to matching branches set to no one (not even admins, with Do not allow bypassing enabled).
• Linear history required — no merge commits. Forces squash- or rebase-merge, making each main commit a single reviewable, revertable unit.
• Required reviews — minimum 1 for low-risk paths, 2 for sensitive paths via CODEOWNERS. Dismiss stale reviews on new commits so a reviewer's approval doesn't carry over after the author force-pushes.
• CODEOWNERS mapping critical paths (/infra/, /auth/, /billing/, /.github/workflows/) to specific owners. Workflows-on-workflows is a common attack vector — protect .github/ aggressively.
• Required status checks — CI must pass: unit tests, integration tests, SAST (e.g. Semgrep), dependency scan (Dependabot/Snyk/Trivy), secret scan (gitleaks), license scan, and the duplicate-Q&A or contract-tests if relevant. Pin the exact check names so they can't be renamed away.
• Signed commits required — see prior answer.
• Conversation resolution required — every PR comment must be resolved before merge.
• No bypass for admins — auditors will ask. The tradeoff: a real emergency (rare) requires temporarily lifting the rule, which is logged in the audit trail and is itself a finding to triage.
• Ticket linking — PR title regex enforced to include JIRA-1234 (or similar). The commit-msg hook on the server rejects PRs without it. Auditors get traceability from ticket → PR → commit → deployment.

Controls on main: Process controls layered on top: Where this hits ergonomics: The principle: make the secure path the easy path. If the protected workflow is faster than circumventing it (because of good tooling, fast CI, and sane PR sizes), engineers stays on it; the policy then enforces itself culturally rather than only via lockdown. --- ## 🟠 Stashing, Tags & Everyday Workflows

• PR templates — checkboxes for "tests added," "security impact considered," "rollback plan." Required for sensitive areas via CODEOWNERS-driven PR templates.
• Production deploy gating — main is continuously deployed to staging, but production promotion goes through a separate change-management workflow (ServiceNow, Linear, etc.) with the deploying engineer different from the commit author. Many auditors require this segregation of duties.
• Audit log retention — Git host audit logs (GitHub Enterprise, GitLab Premium) retained 1+ year and shipped to your SIEM. The audit log captures every protection-rule change, force-push attempt, and admin override.
• Two reviewers required on /auth/ slows urgent fixes — mitigate with a documented break-glass process and clear on-call ownership.
• Required signed commits adds setup friction for new hires — build it into the laptop bootstrap script and have the onboarding checklist verify a signed test commit before they get repo write access.
• Many required checks → slow merges. Invest in CI parallelism and selective testing (run only the affected service's tests when paths under services/foo/ change). Without this, developers will route around the system, defeating the policy.
• "No bypass for admins" feels paranoid until you're sitting in a SOC 2 audit; lean into it and design the emergency process upfront so engineers know what to do without disabling controls.