git-workflowlisted

# Git Workflow and Versioning Git is your safety net: commits are save points, branches are sandboxes, history is documentation. With AI agents generating code at high speed, disciplined version control is what keeps changes manageable, reviewable, and reversible. ## When to use - Committing, branching, or organizing work across parallel streams. - Resolving an in-progress merge or rebase conflict. - Cutting a release, choosing a semantic version bump, tagging, or writing a changelog. - Setting up git guardrails (blocking dangerous commands) or pre-commit hooks. **Not for:** a simple commit of finished work with no conflicts (just commit it); designing CI pipelines (use `ci-cd`); production deployment strategy (use `shipping`). ## Steps ### 1. Work trunk-based with short-lived branches Keep `main` always deployable. Work in short-lived feature branches that merge back within 1–3 days. Long-lived branches are a hidden cost — they diverge, create merge conflicts, and delay integration. DORA research consistently links trunk-based development with high-performing teams. ``` main ──●──●──●──●──●──●──●──●──●── (always deployable) ╲ ╱ ╲ ╱ ●──●─╱ ●──╱ ← short-lived feature branches (1-3 days) ``` Branch naming: `feature/<desc>`, `fix/<desc>`, `chore/<desc>`, `refactor/<desc>`. Delete branches after merge. Prefer feature flags over long-lived branches for incomplete features. For parallel AI-agent work, use git worktrees so each agent works