Git

Commits are save points, branches are disposable, history is read later by people who weren't there. Treat them accordingly.

The project's own conventions override everything below on message format, cadence, branch naming and how a branch lands; a topic branch per task, landed whole, holds in every project. AGENTS.md or a contributing guide states them; where neither mentions the subject, git log is the authority — read the recent subjects and match what the project does, including how a branch lands and whether an agent may run write commands unasked.

Commit messages

Conventional Commits — type(scope): subject. Types: feat, fix, refactor, chore, docs, test, build, ci, perf. Single-line subject, aim under 50 characters and never over 72. The subject names what changed in the plainest words; the why goes in the PR body, where a reviewer reads it beside the diff. Do not hand-write issue references in the subject ((#123), Fixes #123) — those belong in the PR body. A (#N) suffix a squash merge appends is the forge's and stays.

Commit discipline

• Commit after each successful slice (the save-point pattern). A commit is a point you can return to; when exploring an uncertain change, commit early so a dead end reverts cleanly instead of being lost.
• One logical change per commit. A commit that refactors and adds a feature is two commits.

Change sizing