This is the Principal-level systems thinking question — designing the Git governance model, not just using commands.

Production Git standards checklist

Phase 1 — Repository setup:

Branch protection on main: require PR, 1+ approvers, status checks, signed commits

CODEOWNERS file: map directories to owning teams

.gitignore: comprehensive (OS files, IDE files, build artifacts, .env)

.gitattributes: line endings, binary files, LFS configuration

README.md: setup instructions, branching model, PR process

Phase 2 — Developer tooling:

.pre-commit-config.yaml: secrets detection, lint, format, commit-msg

PULL_REQUEST_TEMPLATE.md: standard PR description format

Conventional commits enforced via commitlint

Phase 3 — CI/CD integration:

Required status checks: tests, security scan, lint

Semantic versioning: semantic-release or manual tag policy

Branch → environment mapping: feature/* → preview, main → staging, tag → prod

Phase 4 — Security:

GitHub Advanced Security: secret scanning + code scanning enabled

Audit log streaming to SIEM or GCS

Deploy keys or Workload Identity (no PATs with long expiry)

Signed commits required (SSH or GPG)

Phase 5 — Documentation:

Git workflow documented in team wiki (branching model, release process, hotfix process)

Runbook: what to do if X (force push needed, secret exposed, branch deleted)

A well-governed Git repository is invisible to developers — the guardrails prevent mistakes without getting in the way. The goal: any engineer can contribute safely without knowing every edge case, because the tooling (hooks, branch protection, CI checks) catches problems before they reach production. The Principal Platform Engineer designs this system, documents it, and iterates based on incidents and team feedback.

Measure, then improve: Key Git health metrics: PR cycle time (open to merge), review response time, CI failure rate, force-push incidents, secret scanning alerts per month, branch age P95. Track these on a dashboard. An increase in PR cycle time signals friction in the review process. Force-push incidents signal a gap in branch protection configuration. Data drives improvements rather than opinions.