git-workflow-and-versioning

# Git Workflow and Versioning ## Overview Git is your safety net. Treat commits as save points, branches as sandboxes, and history as documentation. With AI agents generating code at high speed, disciplined version control is the mechanism that keeps changes manageable, reviewable, and reversible. ## When to Use Always. Every code change flows through git. ## Core Principles ### Trunk-Based Development (Recommended) Keep `main` always deployable. Work in short-lived feature branches that merge back within 1-3 days. Long-lived development branches are hidden costs — they diverge, create merge conflicts, and delay integration. DORA research consistently shows trunk-based development correlates with high-performing engineering teams. ``` main ──●──●──●──●──●──●──●──●──●── (always deployable) ╲ ╱ ╲ ╱ ●──●─╱ ●──╱ ← short-lived feature branches (1-3 days) ``` This is the recommended default. Teams using gitflow or long-lived branches can adapt the principles (atomic commits, small changes, descriptive messages) to their branching model — the commit discipline matters more than the specific branching strategy. - **Dev branches are costs.** Every day a branch lives, it accumulates merge risk. - **Release branches are acceptable.** When you need to stabilize a release while main moves forward. - **Feature flags > long branches.** Prefer deploying incomplete work behind flags rather than keeping it on a branch for weeks. ### 1. Commit Early, ...