git
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, and that includes cadence and branching, not just message format. 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 whether it branches at all 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. 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.
- Explain intent, not mechanics. Describe why the change matters, not what files were touched.