Wat maakt een goede commit en commit bericht?

Question

Accepted Answer

Goede commits zijn **gefocust** (één logische wijziging) met **duidelijke berichten** die uitleggen wat is veranderd en waarom. Goed vervaardigde commits en berichten maken de projectgeschiedenis leesbaar, nuttig voor het begrijpen van wijzigingen, debuggen en samenwerking.

## Goede commit berichten

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

## De imperatieve wijs conventie

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

## Goede commits: atomair en gefocust

```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 (een populaire standaard)

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

## Waarom het belangrijk is

Begrijpen wat goede commits en commit berichten maakt is waardevol voor **het creëren van leesbare, nuttige projectgeschiedenis**, dus het is belangrijke praktische kennis die samenwerking en onderhoudbaarheid aanzienlijk beïnvloedt. **Goede commit berichten** zijn belangrijk omdat de commit geschiedenis een cruciale vorm van documentatie is — duidelijke berichten (een beknopt samenvatting die uitlegt *wat* is veranderd, met een body die *waarom* uitlegt wanneer nodig) maken het mogelijk te begrijpen hoe en waarom code is geëvolueerd, wat onschatbaar is bij het bekijken van geschiedenis, debuggen (begrijpen waarom een wijziging is aangebracht), of onboarding.

Vaag berichten ("dingen opgelost", "bijwerken", "wip") maken geschiedenis onbruikbaar, waardoor het onmogelijk is wijzigingen later te begrijpen — een echte kostenpost.

De **imperatieve wijs conventie** ("Feature toevoegen" niet "Feature toegevoegd") is een veel gevolgde standaard die het waard is om te kennen. **Goede commits zijn atomair en gefocust** (elke commit één logische wijziging, niet veel onverwante wijzigingen samengebundeld) is even belangrijk: gefocuste commits zijn veel gemakkelijker om te **reviewen** (reviewers begrijpen één wijziging), **terug te draaien** (één wijziging schoon ongedaan maken zonder anderen te beïnvloeden), begrijpen, en **bisect te gebruiken** (vinden welke commit een bug introduceerde) — dus commit structuur beïnvloedt direct hoe bruikbaar de geschiedenis is voor debuggen en samenwerking.

Weten over **Conventional Commits** (de `type(scope): description` standaard die geautomatiseerde changelogs en versioning mogelijk maakt) is waardevol omdat het veel wordt gebruikt.

Omdat commit geschiedenis belangrijke documentatie is en goede commits/berichten het leesbaar en nuttig maken (voor begrijpen, reviewen, debuggen en samenwerking) terwijl slechte commits het onbruikbaar maken, en omdat het vervaardigde gefocuste commits met duidelijke berichten is een kenmerk van professionele Git praktijk, is het begrijpen wat goede commits en commit berichten maakt waardevol, praktisch relevante kennis voor effectieve samenwerking en onderhoudbare geschiedenis — een vaardigheid die attente developers onderscheidt en het langetermijngebruik en teamworkflow van een project aanzienlijk verbetert.