Git-Commit-Nachrichten-Vorlagen

Wiederverwendbare Conventional-Commit- und PR-fertige Nachrichtenvorlagen, die sich in Ihrem Terminal und Editor erweitern.

Übersicht über die Vorlagenkategorie

Konsistente Commit-Nachrichten machen die Historie eines Repositorys lesbar, ermöglichen automatisierte Changelogs und beschleunigen das Code-Review — aber einen ordentlich strukturierten Conventional Commit jedes Mal von Hand zu tippen ist mühsam genug, dass die meisten Entwickler auf einzeilige Zusammenfassungen zurückfallen. Ein Text-Expander löst das, indem er einen kurzen Trigger in ein vollständiges Commit-Gerüst mit Typ, Scope, Zusammenfassung, Body und Footer verwandelt, sodass Sie die Details ausfüllen, statt sich das Format zu merken. Da Lightning Assist systemweit funktioniert — auch im Terminal, wo die meisten Commits tatsächlich passieren, und in der Commit-Box von VS Code — funktionieren dieselben Vorlagen, egal ob Sie über die Befehlszeile, Ihre IDE oder eine Git-GUI committen. Push-to-Talk-Sprache kann sogar den längeren Body-Absatz diktieren, wenn Ihre Hände mitten im Debuggen von der Tastatur weg sind.

Wann Sie diese Vorlagen verwenden sollten

Verwenden Sie Commit-Nachrichten-Vorlagen bei jedem Commit, aber sie zahlen sich am meisten bei den Commits aus, die später wichtig sind: Bugfixes, die Sie erneut besuchen werden, Breaking Changes, die andere Teams betreffen, und jeder Commit in einem Repo, das Releases oder Changelogs aus der Commit-Historie automatisch generiert. Wenn Ihr Projekt Conventional Commits, semantic-release oder eine Changelog-Automatisierung verwendet, ist ein konsistentes Gerüst nicht nur Ordentlichkeit — es ist das, was die Tooling überhaupt funktionieren lässt. Selbst bei Solo-Projekten spart ein lesbares Git-Log in konsistentem Format echte Zeit, wenn Sie eine Regression bisecten oder sich erinnern wollen, warum eine Änderung vor sechs Monaten gemacht wurde.

Beispielvorlagen in dieser Kategorie

  • Conventional-Commit-Gerüst: Typ, optionaler Scope, Zusammenfassung, Body und Footer mit Ticketreferenz.
  • Fix-Commit mit Bug-Kontext: was kaputt war, der Fix und das Issue, das es schließt.
  • Breaking-Change-Commit: die Änderung plus ein klar markierter BREAKING CHANGE-Footer für Release-Tooling.

Beispielvorlagen in der Praxis

Conventional-Commit-Gerüst

Die alltägliche Vorlage für jeden Commit, nach der Conventional-Commits-Spezifikation, die automatisierte Versionierung und Changelog-Tools antreibt. Die Struktur ist ein Typ (feat, fix, chore, docs, refactor, test usw.), ein optionaler Scope in Klammern, eine prägnante Zusammenfassung im Imperativ unter etwa fünfzig Zeichen, eine Leerzeile, dann ein Body, der das Warum erklärt, und ein Footer für Ticketreferenzen. Behalten Sie dies auf einem kurzen Trigger wie ;cc, damit es sich im Terminal erweitert, bevor Sie die Nachricht schreiben. Ein konsistentes Gerüst jedes Mal auszufüllen ist das, was ein Git-Log Monate später tatsächlich nützlich macht, und es ist der Unterschied zwischen einem Release-Tool, das einen Changelog automatisch generieren kann, und einem, das es nicht kann.

[#type#]([#scope#]): [#summary#]

[#why this change was made#]

Refs: [#ticket#]

Fix-Commit mit Bug-Kontext

Bugfix-Commits sind diejenigen, die Ihr zukünftiges Ich am meisten verstehen muss, also verdienen sie mehr als „fix bug". Erfassen Sie drei Dinge: was kaputt war (das beobachtbare Symptom), was der Fix bewirkt und welches Issue es schließt, damit der Tracker automatisch aktualisiert wird. Der „Closes #"-Footer ist das, was den Commit mit Ihrem Issue-Tracker verknüpft und das Ticket beim Merge auf den meisten Plattformen automatisch schließt. Behalten Sie dies auf einem Trigger wie ;fix. Wenn Sie tief in einer Debugging-Sitzung stecken und die Grundursache in einfachem Deutsch festhalten möchten, lässt Push-to-Talk-Sprache Sie den Body diktieren, ohne den Flow zu unterbrechen, und AI Enhance kann eine weitschweifige diktierte Erklärung in einen sauberen Absatz straffen.

fix([#scope#]): [#what was broken#]

[#root cause and what the fix does#]

Closes #[#issue#]

Breaking-Change-Commit

Wenn ein Commit eine API, ein Konfigurationsformat oder einen anderen Vertrag ändert, von dem anderer Code abhängt, muss der Breaking Change ausdrücklich markiert werden, damit Release-Tooling einen Major-Versionssprung auslöst und der Changelog die Nutzer warnt. Der Conventional-Commits-Standard verwendet dafür einen BREAKING CHANGE:-Footer (oder ein ! nach dem Typ). Erklären Sie, was kaputtging, und vor allem, was Verbraucher tun müssen, um zu migrieren — ein Breaking Change ohne Migrationsnotiz wird einfach zu einer Flut von Support-Fragen. Behalten Sie dies auf einem bewussten Trigger wie ;ccbreak, damit Sie nur danach greifen, wenn Sie es wirklich meinen, denn einen Breaking Change falsch zu kennzeichnen ist schlimmer als ihn nicht zu kennzeichnen.

[#type#]([#scope#])!: [#summary#]

[#what changed#]

BREAKING CHANGE: [#what consumers must change to migrate#]

Refs: [#ticket#]

So fangen Sie an

Beginnen Sie mit dem allgemeinen Conventional-Commit-Gerüst auf einem kurzen Trigger wie ;cc, mit Platzhaltern für Typ, Scope, Zusammenfassung, Body und Ticket. Fügen Sie eine ;fix-Variante hinzu, vorausgefüllt mit dem fix-Typ und einem „Closes #"-Footer, und eine ;ccbreak-Variante mit dem BREAKING CHANGE-Footer für die seltenen, aber wichtigen Breaking Commits. Tippen Sie den Trigger in Ihrem Terminal oder der Commit-Box Ihres Editors und er erweitert sich inline beim Tippen — kein Hotkey nötig, und er funktioniert in beiden gleich, weil die Erweiterung systemweit ist. Wenn die Gerüste sich natürlich anfühlen, fügen Sie PR-Beschreibungs- und Code-Review-Antwortvorlagen hinzu, damit der gesamte Änderungs-Einreichungsfluss konsistent ist.

Profi-Tipps

  • Halten Sie die Zusammenfassungszeile unter ~50 Zeichen und im Imperativ („add", nicht „added") — die meisten Git-Tools und Reviewer erwarten diese Konvention.
  • Verwenden Sie einen „Closes #[issue]"-Footer bei Fix-Commits, damit das Mergen der Änderung das verknüpfte Ticket in Ihrem Tracker automatisch schließt.
  • Reservieren Sie die Breaking-Change-Vorlage für echte Vertragsänderungen und fügen Sie immer den Migrationsschritt hinzu — eine Breaking-Notiz ohne ihn erzeugt nur Support-Last.
  • Diktieren Sie den Commit-Body mit Push-to-Talk, wenn Ihre Hände mitten im Debuggen von der Tastatur weg sind, und straffen Sie dann die Formulierung mit AI Enhance.

Verwenden Sie diese Vorlagen in jeder App

Erstellen Sie aus diesen Beispielen wiederverwendbare Snippets und führen Sie sie mit Schnellzugriff, Trigger-Verknüpfungen oder KI-Verbesserungen aus.

Kostenlose Testversion starten

Verwandte Seiten und Snippets

Entdecken Sie verwandte Leitfäden, Vorlagen und Vergleiche für Ihren Workflow.