Hvad gør et godt commit og en god commit-besked?

Question

Accepted Answer

Gode commits er **fokuserede** (én logisk ændring) med **klare beskeder**, der forklarer, hvad der blev ændret og hvorfor. Velskrevne commits og beskeder gør projekthistorikken læsbar og brugbar til at forstå ændringer, debuggering og samarbejde.

## Gode commit-beskeder

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

## Imperativ stemning-konventionen

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

## Gode commits: atomare og fokuserede

```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 (en populær 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.
```

## Hvorfor det betyder noget

At forstå, hvad der gør commits og commit-beskeder gode, er værdifuldt for **at skabe læsbar, brugbar projekthistorik**, så det er vigtig praktisk viden, der betydeligt påvirker samarbejde og vedligeholdelsesmuligheder. **Gode commit-beskeder** betyder noget, fordi commit-historikken er en vigtig form for dokumentation — klare beskeder (en kortfattet sammenfatning, der forklarer *hvad* der blev ændret, med en body, der forklarer *hvorfor*, når det er nødvendigt) gør det muligt at forstå, hvordan og hvorfor koden udviklede sig, hvilket er uvurderligt når man gennemser historikken, debugger (forstår hvorfor en ændring blev foretaget), eller onboarder.

Vage beskeder ("fixed stuff", "update", "wip") gør historikken ubrugelig, hvilket gør det umuligt at forstå ændringer senere — en reel omkostning.

Konventionen for **imperativ stemning** ("Add feature" ikke "Added feature") er en udbredt standard, der er værd at kende. **Gode commits, der er atomare og fokuserede** (hvert commit én logisk ændring, ikke mange uafhængige ændringer slået sammen) er lige så vigtig: fokuserede commits er langt lettere at **gennemgå** (anmeldere forstår én ændring), **fortryde** (fortryde én ændring uden at påvirke andre), forstå og **bisect** (finde hvilket commit, der introducerede en bug) — så commit-struktur påvirker direkte, hvor brugbar historikken er til debugging og samarbejde.

At kende **Conventional Commits** (standarden `type(scope): description`, der muliggør automatiserede changelogs og versioner) er værdifuldt, da det er bredt adopteret.

Da commit-historikken er vigtig dokumentation og gode commits/beskeder gør den læsbar og brugbar (til at forstå, gennemgå, debugge og samarbejde), mens dårlige gør den ubrugelig, og da det at skrive fokuserede commits med klare beskeder er et kendetegn på professionel Git-praksis, er det værdifuldt, praktisk relevant viden at forstå, hvad der gør commits og commit-beskeder gode for effektivt samarbejde og vedligeholdbar historik — en færdighed, der adskiller omtankefulde udviklere og forbedrer meningsfuldt et projekts langsigtede brugbarhed og teamworkflow.