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.

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.

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.

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.

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.

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.