Write useful commit messages

A commit message should help someone understand the purpose without opening the diff first.

Use a short command-style subject:

Add password reset form

This reads naturally after the phrase: “If applied, this commit will…”

Avoid messages such as changes, stuff, or fix. The diff shows the changed lines. The message should name the result or intent.

Subject and body

For a change that needs more context, let Git open your editor:

git commit

Write a concise subject, leave a blank line, then explain why the change exists and any decision that is not obvious from the code.

The subject line is what shows up in git log --oneline. The body is for context that does not fit in one line.

Before committing, inspect git diff --staged. A good message describes that exact snapshot, not all the work you did during the day.

My advice is to write the message after you review the staged diff, not before. The diff tells you what actually changed.

Bad messages make git bisect painful. When you hunt for the commit that broke production, you read dozens of subjects. Update files tells you nothing.

Keep the subject under about 50 characters when you can. Long subjects truncate awkwardly in terminal tools and hosting UIs.

Use the imperative mood: Add, Fix, Remove, not Added or Fixes. You are describing what the commit will do to the codebase.

Try this on your own project: compare these messages: Update files, Fix login, and Reject expired password reset links. Which one will help you most six months from now, and why?