What makes a commit message good?

A good message explains what changed and why, is clear and concise, and is usually written in the imperative mood ("Add", "Fix", not "Added" or "Changes"). Also, commits should be atomic: each commit does a single logical thing. Many teams follow the Conventional Commits convention (feat:, fix:, etc.).

The commit history is documentation. A bad message like cambios or fix tells your future self and your teammates nothing.

Best practices:

• Imperative mood: "Add validation", not "Added validation". It's the Git convention (it completes the phrase "this commit will...").
• Concise but clear: a short summary line (around 50 characters). If more context is needed, a body separated by a blank line.
• Explain the why: the what is visible in the diff; only you know the why.
• Atomic commits: each commit one single logical thing. Don't mix a fix with a refactor and three features.

Conventional Commits is a popular convention with prefixes: feat: (new feature), fix: (a fix), docs:, refactor:, test:, chore:.

# Bad: says nothing
git commit -m "cambios"
git commit -m "fix"

# Good: imperative, clear, says what it does
git commit -m "Agrega validacion de email en el formulario de registro"
git commit -m "Corrige calculo del total cuando el carrito esta vacio"

# With Conventional Commits (type prefix)
git commit -m "feat: agrega login con Google"
git commit -m "fix: corrige fuga de memoria en el listener del scroll"

# Message with a body (summary + explanation of the why)
git commit -m "fix: evita doble envio del formulario" -m "El boton no se deshabilitaba tras el primer click, generando pedidos duplicados."

Writing useless messages (cambios, asdf, wip) or cramming too many things into a single commit (a "mega commit"). Also, describing what you did in an obvious way ("modify file") instead of the why. A clean history saves a huge amount of time when debugging or doing git revert.

"A good message explains what changed and above all why, clearly and concisely, usually in the imperative, like 'Add validation' or 'Fix the total'. I also aim for atomic commits: each commit does a single logical thing, so the history is easy to read and to revert. On teams I usually follow Conventional Commits with prefixes like feat: or fix:. The history is documentation, so I avoid messages like 'changes' or 'wip'."