O que faz um bom commit e uma boa mensagem de commit?

Question

Accepted Answer

Bons commits são **focados** (uma mudança lógica) com **mensagens claras** que explicam o que mudou e por quê. Commits e mensagens bem elaborados tornam o histórico do projeto legível, útil para compreender mudanças, depuração e colaboração.

## Boas mensagens de commit

```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
```

## A convenção do imperativo

```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).
```

## Bons commits: atômicos e focados

```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 (um padrão popular)

```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.
```

## Por que isso importa

Compreender o que faz bons commits e mensagens de commit é valioso para **criar um histórico de projeto legível e útil**, portanto é um conhecimento prático importante que afeta significativamente a colaboração e a manutenibilidade. **Boas mensagens de commit** importam porque o histórico de commits é uma forma crucial de documentação — mensagens claras (um resumo conciso explicando *o que* mudou, com um corpo explicando *por quê* quando necessário) tornam possível entender como e por que o código evoluiu, o que é inestimável ao revisar histórico, depurar (entender por que uma mudança foi feita) ou integrar novos membros.

Mensagens vagas ("corrigido", "atualização", "wip") tornam o histórico inútil, impossibilitando a compreensão de mudanças depois — um custo real.

A **convenção do imperativo** ("Adicionar recurso" e não "Adicionado recurso") é um padrão amplamente seguido que vale a pena conhecer. **Bons commits sendo atômicos e focados** (cada commit uma mudança lógica, não muitas mudanças não relacionadas juntas) é igualmente importante: commits focados são muito mais fáceis de **revisar** (revisores entendem uma mudança), **reverter** (desfazer uma mudança limpar sem afetar outras), entender e **bissecar** (encontrar qual commit introduziu um bug) — portanto a estrutura de commit afeta diretamente como o histórico é utilizável para depuração e colaboração.

Conhecer sobre **Conventional Commits** (o padrão `tipo(escopo): descrição` que permite changelogs automatizados e versionamento) é valioso, pois é amplamente adotado.

Como o histórico de commits é documentação importante e bons commits/mensagens tornam-no legível e útil (para entender, revisar, depurar e colaborar) enquanto os ruins o tornam inútil, e como elaborar commits focados com mensagens claras é uma característica de prática Git profissional, compreender o que faz bons commits e mensagens de commit é conhecimento valioso e praticamente relevante para colaboração efetiva e histórico manutenível — uma habilidade que distingue desenvolvedores reflexivos e melhora significativamente a usabilidade e fluxo de trabalho em equipe de um projeto a longo prazo.