git-workflow-and-versioning

Use the format 'type: short description' where type is feat, fix, refactor, test, docs, or chore. The message should explain why the change was made, not just what changed, with an optional body describing intent and context.

Stage and commit each logical change separately: one commit per self-contained increment such as an endpoint, a form component, or tests. Keep formatting changes, refactors, and features in separate commits targeting roughly 100 lines each.

Trunk-based development keeps main always deployable with short-lived feature branches merged within 1-3 days, while gitflow uses long-lived development branches. Short branches reduce merge conflicts and integration delays; commit discipline matters more than the specific branching model.

Bump MAJOR for breaking changes requiring consumers to modify their code, MINOR for backward-compatible new functionality, and PATCH for backward-compatible bug fixes. When unsure whether a change is breaking, assume it is.

Yes, use git worktrees to give each agent its own directory checked out to a separate branch. This avoids branch switching conflicts, and failed experiments can be discarded by removing the worktree without losing other work.

Commit messages are written for developers, while changelogs answer 'what changed and do I care?' for consumers. A changelog curates entries by impact (Added, Changed, Fixed, Deprecated, Removed, Security) and should be written alongside each change, not reconstructed at release time.