Version Control Checklist

Seed the repo with a README that names the service, owners, and how to run it locally. Use a language-appropriate .gitignore from github/gitignore — committing build artifacts and node_modules is one of the most common rookie mistakes and is painful to undo from history.

Pick a license (MIT, Apache 2.0, or proprietary) before any external contributor sees the repo — adding one later requires every prior contributor's sign-off. CODEOWNERS routes review automatically; without it, PRs get stuck waiting for the wrong people.

Public repos require contributor-facing files (CONTRIBUTING, CODE_OF_CONDUCT) and a license that permits external use. Private repos skip those but should still capture internal contribution norms.

For public repos, GitHub surfaces these files in the contribution flow. Use the Contributor Covenant for the code of conduct; the CONTRIBUTING file should describe branching, commit format, and how to run tests locally.

Pick one model — trunk-based with short-lived feature branches, GitHub Flow, or Git-flow with develop/release branches — and write it into CONTRIBUTING. Mixing models silently is how teams end up with abandoned long-lived branches and merge conflicts that take days to resolve.

Require pull requests, dismiss stale reviews on new commits, require linear history, and block force pushes. Without protection rules, a single git push --force can silently rewrite shared history.

Turn on the repo setting that deletes head branches after merge. Schedule a monthly prune of stale remote branches older than 90 days — repos with hundreds of dead branches make git branch output unreadable and slow down clones.

Use the feat:, fix:, chore:, docs:, refactor: prefix convention. It enables automated CHANGELOG generation (semantic-release, release-please) and makes git log --oneline actually useful during incident triage.

Wire gitleaks or trufflehog into a pre-commit hook (use the pre-commit framework). Once a secret lands in git history, rotation is necessary but not sufficient — the value lives in every clone forever unless you rewrite history with git-filter-repo or BFG.

Branch protection should reject direct pushes from everyone, including admins (uncheck "allow administrators to bypass"). Every change goes through a PR — this is the audit trail SOC 2 change-management controls require.

Map sensitive directories (auth, billing, infra/, migrations/) to the engineers who actually know them. "LGTM" reviews from people who can't read the diff are how regressions ship; CODEOWNERS routes the right eyes to the right code.

Mark the lint, type-check, unit-test, and SAST jobs as required status checks. The biggest anti-pattern is letting reviewers merge red because "the test is flaky" — quarantine flaky tests in a separate suite instead.

Set a soft cap (e.g., 400 lines changed) and ask authors to split larger PRs. Review quality drops sharply past that threshold; reviewers skim and miss real issues. Configure a danger.js or PR-size-labeler bot to warn automatically.

Squash-and-merge keeps main's history linear and one-commit-per-feature; rebase-and-merge preserves authored commits. Disable the merge-commit option unless you have a reason — merge commits clutter git log on main.

Use vMAJOR.MINOR.PATCH per semver.org. Bump MAJOR on breaking API changes, MINOR on new features, PATCH on fixes. Sign tags with GPG or sigstore so consumers can verify provenance — increasingly required for SLSA and federal SBOM compliance.

Follow keepachangelog.com — group entries under Added / Changed / Deprecated / Removed / Fixed / Security. Tools like release-please can generate this from Conventional Commits, but a human should still review wording before publishing.

Build the artifact from the tagged sha, not from a moving branch. "Deployed from main" is how you end up unable to reproduce a build six months later when chasing a regression.

Run the synthetic critical-path checks (auth, checkout, primary read path) against the deployed artifact. If smoke fails, the previous tag's container image must still be in the registry — verify before cutting, not during the rollback.

Redeploy the prior signed tag's container image; revert any forward-only DB migration via the documented rollback script. Open a SEV2 incident and file a hotfix branch off the prior tag, not off main.

Install the GitHub-Jira or GitHub-Linear integration so commit messages and PR titles containing the issue key auto-link both ways. This is the cheapest audit trail for change management — every shipped commit traces back to an approved ticket.

Add .github/pull_request_template.md and .github/ISSUE_TEMPLATE/ with prompts for context, testing steps, and rollout plan. Without templates, PR descriptions devolve to one-liners and reviewers waste time asking for the same context every time.

Post the release notes to #engineering and the customer-facing changelog. Record the URL here so support, sales, and the on-call engineer all reference the same source of truth during the post-release watch window.