Yes this is another guide to commit messages but hear me out. Good commits save time later and prevent you from becoming the archaeologist who digs through commit logs at 2 a m while regretting every life decision. This short guide gives rules that actually help teammates and tools understand why code changed not just what you typed into your editor.

Quick rules for sane commit messages

• Keep the subject short Aim for under 50 characters so logs stay scannable in terminals and GUIs.
• Use the imperative mood Write the subject like an instruction Add feature or Fix bug instead of Added or Fixed
• Separate subject and body with a blank line Tools and humans both appreciate this small act of kindness
• Explain why and what changed not how The code shows the how The message should explain the reason and the scope
• Wrap the body at about 72 characters This keeps diffs and email views neat
• Reference issues and tests when relevant Include ticket numbers or test names to speed up context hunting
• Follow repo conventions Consistency beats cleverness when your team is reading history

Subject line examples

Fix parser crash on empty input
Add user profile validation
Remove deprecated api call

Short and useful is the goal If you need five lines to explain the change then put the short headline in the subject and the rest in the body

What to put in the body

The body is your chance to be helpful not chatty Start with why this change was made and the scope of the fix or feature Then add any important implementation notes that a future developer would want to know

• Why did we change this The root cause or user problem
• What areas are affected Modules, APIs or performance implications
• How to verify Tests to run or steps to reproduce
• References Issue numbers pull requests and test identifiers

Checklist before you commit

• Is the subject under 50 characters
• Does the subject use imperative mood
• Is there a blank line between subject and body
• Does the body explain why and how to verify
• Did you follow the repository prefix or scope conventions

Semantic commits and repository conventions

Many teams use a small set of types like feat fix chore docs test refactor style perf build ci and so on Add an optional scope in parentheses to show the affected area for example fix(parser) Short subjects with types help automation and release tooling when configured in CI systems such as GitHub Actions GitLab pipelines or Bitbucket pipelines

Copy paste friendly template

Short imperative subject under 50 characters

Explain why the change was needed and what was done
Describe how to verify and mention tests if any
Refs #123 or related ticket numbers

Parting advice

Good commit messages are a small social contract with your future self and your team They reduce annoying detective work and make churn easier to understand If you are ever tempted to write a diary entry as a commit message ask yourself will this help someone debug this code in six months If the answer is no then move it to the PR description or your personal notes

Now go write tidy commits and spare future you from late night archaeology