What makes a good commit and commit message?

Question

Accepted Answer

Good commits are **focused** (one logical change) with **clear messages** that explain what changed and why. Well-crafted commits and messages make project history readable, useful for understanding changes, debugging, and collaboration.

## Good commit messages

```text
GOOD message structure:
  Short summary line (~50 chars, imperative mood, capitalized, no period)
  <blank line>
  Optional body: explain WHAT and WHY (not how — the code shows how),
  wrap at ~72 chars. Reference issues if relevant.
```

```text
✅ GOOD:
  Add user email validation to registration form

Validate email format before submission to prevent invalid
  accounts. Fixes #142.

❌ BAD:
  "fixed stuff", "update", "asdf", "changes", "wip"
  → vague, uninformative — useless when reviewing history later
```

## The imperative mood convention

```text
Write the summary as a COMMAND/instruction (imperative):
  ✓ "Add feature", "Fix bug", "Update docs", "Remove dead code"
  ✗ "Added feature", "Fixes bug", "Updating docs"
→ Convention: it reads as "this commit will [Add feature]" (matches Git's own messages).
```

## Good commits: atomic and focused

```text
✓ ATOMIC — each commit is ONE logical change (not many unrelated changes lumped together)
✓ Focused — "Add login" and "Fix typo" are SEPARATE commits, not one
✓ Working — ideally each commit leaves the code in a working state
Why: focused commits are easier to REVIEW, REVERT (undo one change cleanly),
  understand, and bisect (find which commit introduced a bug).
```

## Conventional Commits (a popular standard)

```text
type(scope): description    → feat: add login | fix: handle null | docs: update README
  types: feat, fix, docs, refactor, test, chore, etc.
→ Enables automated changelogs/versioning; widely adopted in many projects.
```

## Why it matters

Understanding what makes good commits and commit messages is valuable for **creating readable, useful project history**, so it's important practical knowledge that significantly affects collaboration and maintainability. **Good commit messages** matter because the commit history is a crucial form of documentation — clear messages (a concise summary explaining *what* changed, with a body explaining *why* when needed) make it possible to understand how and why code evolved, which is invaluable when reviewing history, debugging (understanding why a change was made), or onboarding.

Vague messages ("fixed stuff", "update", "wip") render history useless, making it impossible to understand changes later — a real cost.

The **imperative mood convention** ("Add feature" not "Added feature") is a widely-followed standard worth knowing. **Good commits being atomic and focused** (each commit one logical change, not many unrelated changes lumped together) is equally important: focused commits are far easier to **review** (reviewers understand one change), **revert** (undoing one change cleanly without affecting others), understand, and **bisect** (finding which commit introduced a bug) — so commit structure directly affects how usable the history is for debugging and collaboration.

Knowing about **Conventional Commits** (the `type(scope): description` standard enabling automated changelogs and versioning) is valuable as it's widely adopted.

Since commit history is important documentation and good commits/messages make it readable and useful (for understanding, reviewing, debugging, and collaboration) while poor ones make it useless, and since crafting focused commits with clear messages is a hallmark of professional Git practice, understanding what makes good commits and commit messages is valuable, practically-relevant knowledge for effective collaboration and maintainable history — a skill that distinguishes thoughtful developers and meaningfully improves a project's long-term usability and team workflow.