Commit-Nachricht
Schritte
- Führe
git diff --staged aus, um zu sehen, was committet wird. Wenn nichts bereitgestellt ist, sage dies und frage, ob alles (git add -A) oder bestimmte Dateien bereitgestellt werden sollen. Committe niemals ungestaffelte Änderungen ohne Nachfrage.
- Führe
git log --oneline -15 aus und passe den Stil an, den du siehst: Conventional Commits (feat(api): …), ein Ticket-Präfix (ABC-123 …) oder einfache Sätze. Wenn es keine klare Konvention gibt, verwende einfache Imperativsätze.
- Wenn die bereitgestellten Änderungen mehrere nicht zusammenhängende Dinge tun, schlage vor, sie in separate Commits aufzuteilen, bevor du eine Nachricht für alles schreibst.
Format
<Zusammenfassungszeile, Imperativform, max. ~72 Zeichen, kein Punkt am Ende>
<Body: warum die Änderung vorgenommen wurde und alles, was ein Prüfer nicht im Diff sehen kann.
Umbrüche bei 72 Zeichen. Für triviale Änderungen den Body weglassen.>
<Trailer: Fixes #123, Co-authored-by: …, BREAKING CHANGE: …>
- Imperativform: "Add retry to upload", nicht "Added" oder "Adds".
- Die Zusammenfassung sagt, was sich für den Benutzer oder die Codebasis geändert hat, nicht welche Dateien betroffen sind.
- Der Body erklärt warum: den Fehler, die Einschränkung, die Alternative, die du verworfen hast. Der Diff zeigt bereits was.
- Bei Conventional Commits wähle den Typ ehrlich:
feat (neues Verhalten), fix (Fehler), refactor (keine Verhaltensänderung), perf, docs, test, build, ci, chore. Markiere Breaking Changes mit ! und einem BREAKING CHANGE:-Trailer.
Beispiele
fix(auth): refresh the token before it expires, not after
Requests made in the last 30 seconds of a token's life failed with 401
because the refresh only ran on the first failure. Refresh when less than
60 seconds remain instead.
Fixes #482
Remove unused CSV export endpoint