Useful Git commit messages
↑A useful commit is small enough to understand and has a message that explains what changed and, when not obvious, why. Avoid empty messages such as stuff, fix or update files; they make regressions and code review harder to investigate.
A simple pattern
Section titled “A simple pattern”fix: prevent duplicate inventory items after reconnect
Reuse server-provided item IDs when merging a reconnect snapshot.This makes repeated reconnect messages idempotent.Keep the first line focused and the body limited to relevant context. Your team may use Conventional Commits, but the essential goal is understandability rather than a mandatory prefix. Link an issue when useful without inserting sensitive data.
Before committing
Section titled “Before committing”Review your diff, select relevant hunks, run available tests, and ensure generated files and credentials are not accidentally staged. If a single commit combines unrelated changes, split it into logical commits. Never rewrite published shared history casually just to improve the appearance of a log.
Traceability
Section titled “Traceability”A commit message, branch, issue, review and deployment identifier should let someone understand a change weeks later. The message doesn’t need to repeat every detail that belongs in the pull request; it should preserve the key decision.