The diff already tells you what

A commit message that says "Updated user controller" is wasted bytes - git diff already shows the user controller was updated. The valuable part of a commit message is the why: what problem does this solve, what alternatives were considered, what subtle assumption is the reader missing?

The seven-rule format

Tim Pope's classic seven rules still hold up:

• Separate subject from body with a blank line.
• Limit the subject line to 50 characters.
• Capitalise the subject.
• Do not end the subject with a period.
• Use the imperative mood ("Fix bug", not "Fixed bug").
• Wrap the body at 72 characters.
• Use the body to explain what and why, not how.

An example

git commit -m "Reject negative quantities in checkout

Customers were able to submit negative quantities by editing the
DOM, leading to credits being applied to the order total. We add
server-side validation in CheckoutValidator because client-side
checks alone are insufficient against scripted clients.

The validator throws InvalidQuantityException, which the global
handler converts to a 400 response. Existing tests for zero and
decimal quantities continue to pass."

Conventional Commits

For projects that automate changelogs and version bumps, the Conventional Commits standard adds a structured prefix:

git commit -m "feat(checkout): reject negative quantities"
git commit -m "fix(auth): handle expired refresh tokens"
git commit -m "docs(readme): clarify install steps"

Tooling like semantic-release, standard-version, and changesets reads these prefixes to decide whether the next release is a major, minor, or patch bump.

Templates make it automatic

Configure a commit template so every git commit opens with a structured prompt:

cat > ~/.gitmessage 'EOF'
# Subject (50 chars max)

# Why is this change necessary? (wrap at 72 chars)

# How does it address the problem?

# Side effects, follow-ups, links?
EOF
git config --global commit.template ~/.gitmessage

Reference issues

Linking commits to issues turns your history into a navigable graph. Use the trailer convention so tools and humans both pick up the link:

git commit -m "Fix avatar upload race condition

See: PROJ-2207
Co-authored-by: Alex Tan "

Review your message

Before pushing, run git log -1 and read the message back as if you were a reviewer six months from now. If it does not answer "why was this done?", rewrite it. The five minutes you spend on a good commit message will save the next person hours of code archaeology.