← Blog · 9. April 2026 · ConvertCaseHQ-Team · 7 Min. Lesezeit

Git-Commit-Messages richtig schreiben: Betreff, Großschreibung, Zeilenlänge

Eine saubere Git-Commit-Message hat eine kurze Betreffzeile (Ziel: 50 Zeichen) im Imperativ, im Englischen also „Add“ statt „Added“, ohne Punkt am Ende. Danach folgt eine Leerzeile und dann ein Body, der bei 72 Zeichen umbrochen ist und erklärt, warum die Änderung gemacht wurde. Bei der Großschreibung wählst du eine Konvention und bleibst dabei: Steht ein Präfix wie feat: oder docs: davor, schreibt man das Wort danach meist klein; ohne Präfix lautet der klassische Rat, das erste Wort großzuschreiben.

Nichts davon erzwingt Git selbst, deshalb franst eine Historie mit der Zeit aus. Unten stehen die Regeln, woher jede stammt und wie du deine Werkzeuge sie prüfen lässt, damit du dir nichts merken musst. Die Beispiele sind englisch, denn die genannten Konventionen gelten für englische Commit-Messages.

Aufbau einer guten Commit-Message

fix(editor): keep cursor position after paste

Pasting into an empty textarea moved the cursor to the start, because
the change handler replaced the value before restoring the selection.
Restore the selection after updating the value instead.

Fixes #142

Drei Teile: ein Betreff, der sagt, was der Commit tut, ein Body, der sagt, warum, und optionale Footer für Verweise und Metadaten. Die Dokumentation von Git selbst empfiehlt, mit „a single short (no more than 50 characters) line summarizing the change, followed by a blank line and then a more thorough description“ zu beginnen (einer einzelnen kurzen Zeile von höchstens 50 Zeichen, die die Änderung zusammenfasst, gefolgt von einer Leerzeile und einer ausführlicheren Beschreibung). Alles bis zur ersten Leerzeile gilt als Titel des Commits, und den zeigen git log --oneline, git shortlog und git format-patch an.

Die Betreffzeile: kurz, im Imperativ, ohne Punkt

50 Zeichen sind eine weiche Grenze. Der Leitfaden SubmittingPatches des Git-Projekts nennt sie genau so und bittet Mitwirkende, „skip the full stop“ (den Punkt am Ende wegzulassen). Kommst du nicht unter 50, ist das oft ein Zeichen, dass der Commit zwei Dinge tut.

Derselbe Leitfaden verlangt, „describe your changes in imperative mood“ (beschreibe deine Änderungen im Imperativ), als würdest du der Codebasis Befehle geben: „make xyzzy do frotz“, nicht „makes xyzzy do frotz“ oder „changed xyzzy to do frotz“. Ein praktischer Test aus Chris Beams' sieben Regeln für Commit-Messages: Ein guter Betreff vervollständigt den Satz „If applied, this commit will …“ (Wenn er angewendet wird, wird dieser Commit …).

• „If applied, this commit will add CSV export“ funktioniert.
• „If applied, this commit will added CSV export“ funktioniert nicht.
• „If applied, this commit will bug fixes“ funktioniert ebenfalls nicht und sagt dem Leser nichts.

Der Imperativ passt auch zu den Messages, die Git selbst für dich schreibt, etwa Merge branch 'main' und Revert "…", sodass sich deine eigenen Commits im Log genauso lesen.

Großschreibung im Betreff: die zwei Lager

Hier widersprechen sich die Ratschläge tatsächlich, und die richtige Antwort hängt davon ab, ob deine Betreffzeilen mit einem Präfix beginnen.

Die Variante des Git-Projekts hat ein Detail, das sich zu übernehmen lohnt. Nur das erste Wort nach dem Präfix verliert seinen Großbuchstaben, und nur weil es das erste Wort ist: Wörter, die immer großgeschrieben werden, bleiben so. Das eigene Beispiel des Projekts ist refs: HEAD is also treated as a ref, denn HEAD schreibt man immer in Großbuchstaben. Dieselbe Logik ergibt fix: handle iOS paste und docs: update README badges.

Unsere Meinung: Mit Präfix schreibst du das erste Wort klein, außer es ist ein Name oder ein Akronym. Ohne Präfix schreibst du es groß. Die Stile zu mischen ist der einzige echte Fehler, denn git log --oneline macht aus deinen Betreffzeilen eine Liste, und eine Liste, in der alle paar Zeilen die Schreibweise wechselt, wirkt nachlässig. Dieselbe Überlegung für Dokumentation findest du in unserem Ratgeber zu einheitlicher Dokumentation.

Was die Conventional-Commits-Spezifikation wirklich sagt

Die Conventional-Commits-Spezifikation 1.0.0 definiert diese Struktur:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Die wichtigsten Regeln in Kürze:

• feat (ein neues Feature) und fix (ein Bugfix) sind die zwei Typen, die die Spezifikation definiert, und sie entsprechen MINOR- und PATCH-Releases im Semantic Versioning, wobei Breaking Changes MAJOR entsprechen. Weitere Typen sind erlaubt; die Spezifikation nennt build, chore, ci, docs, style, refactor, perf und test, wie sie die conventional-Konfiguration von commitlint empfiehlt, die auf der Konvention von Angular beruht.
• Ein Breaking Change wird mit ! vor dem Doppelpunkt (feat!: drop Node 16 support) oder mit einem Footer BREAKING CHANGE: gekennzeichnet, und dieser Footer muss in Großbuchstaben stehen.
• Werkzeuge, die das Format lesen, dürfen nicht zwischen Groß- und Kleinschreibung unterscheiden, außer bei BREAKING CHANGE. Zur Frage, ob Typen klein- oder großgeschrieben werden sollen, sagt die FAQ der Spezifikation, es dürfe jede Schreibweise verwendet werden, „but it's best to be consistent“ (am besten ist es aber, einheitlich zu bleiben).

Die Spezifikation legt weder eine Länge für den Betreff fest noch verlangt sie den Imperativ. Das stammt aus der Git-Konvention.

Wo commitlint strenger ist als die Spezifikation

@commitlint/config-conventional von commitlint ist der übliche Weg, das Format durchzusetzen, und seine Voreinstellungen gehen weiter als die Spezifikation. Wir haben Beispiel-Betreffzeilen durch Version 21 laufen lassen:

Auf die README-Zeile solltest du achten. Ein Betreff, der mit einem Akronym oder einem Klassennamen beginnt, etwa fix: README typo oder feat: URLSearchParams support, wird abgelehnt, obwohl das Git-Projekt das Äquivalent akzeptieren würde. Formuliere so um, dass das Akronym nicht am Anfang steht, oder lockere die Regel subject-case in deiner Konfiguration. Das voreingestellte Limit für den Header liegt bei 100 Zeichen, commitlint hält dich also auch nicht auf 50.

Der Body: bei 72 umbrechen und erklären, warum

Git bricht deine Message nie neu um. Tim Popes Erklärung von 2008 gilt weiterhin: git log rückt Messages um vier Leerzeichen ein, auf einem Terminal mit 80 Spalten bleiben mit vier weiteren für die Symmetrie rechts also 72 Spalten, und umbrochener Text bleibt auch lesbar, wenn Commits mit git format-patch per E-Mail verschickt werden. Unser Werkzeug Text auf N Zeichen umbrechen bricht einen Absatz an Wortgrenzen bei 72 Zeichen um, falls dein Editor das nicht kann.

Nutze den Body für das, was der Diff nicht zeigen kann: das Problem, warum gerade diese Lösung und alles, was du versucht hast und was nicht funktioniert hat. Auf der Kommandozeile wird jedes -m zu einem eigenen Absatz, sodass git commit -m "fix: keep cursor after paste" -m "Pasting into…" einen Betreff, eine Leerzeile und einen Body erzeugt.

Lass deine Werkzeuge prüfen

• VS Code: Setze "git.inputValidation": true. Das Commit-Feld warnt dann, wenn der Betreff über 50 Zeichen hinausgeht (git.inputValidationSubjectLength) oder eine andere Zeile über 72 (git.inputValidationLength).
• Vim: Die mitgelieferten Einstellungen für Commit-Messages brechen den Body bei 72 um (textwidth=72) und hören nach 50 Zeichen auf, den Betreff hervorzuheben.
• Eine Commit-Vorlage: git config commit.template ~/.gitmessage startet jeden Commit mit deinen Erinnerungen im Editor.
• Ein commit-msg-Hook für Prüfungen ohne Abhängigkeiten. Speichere dies als .git/hooks/commit-msg und mach die Datei ausführbar:

#!/bin/sh
# Checks the subject line of every commit message.
subject=$(head -n 1 "$1")
length=${#subject}   # counts bytes in some shells; fine for ASCII subjects

if [ "$length" -gt 72 ]; then
  echo "commit-msg: subject is $length characters (limit 72, aim for 50)" >&2
  exit 1
fi
if [ "$length" -gt 50 ]; then
  echo "commit-msg: note, subject is $length characters (aim for 50)" >&2
fi
case "$subject" in
  *.) echo "commit-msg: drop the full stop at the end of the subject" >&2
      exit 1 ;;
esac
if [ -n "$(sed -n 2p "$1")" ]; then
  echo "commit-msg: leave line 2 blank, between subject and body" >&2
  exit 1
fi

Der Hook warnt ab 50 Zeichen und lehnt Betreffzeilen über 72 Zeichen, einen Punkt am Ende und eine fehlende Leerzeile ab; git commit --no-verify überspringt ihn, wenn du es wirklich brauchst. Für einen schnellen Blick auf die Länge vor dem Commit füge den Betreff in unseren Zeichenzähler ein.

Die Checkliste also: Betreff im Imperativ, etwa 50 Zeichen, kein Punkt am Ende, eine Großschreibungsregel für das ganze Repository, eine Leerzeile, ein Body mit Umbruch bei 72, der erklärt, warum, und ein Hook oder Linter, damit die Regeln auch eine hektische Woche überstehen.