machichdigital

IDE-Tools · Foto: Homedust, CC BY 2.0

RuleWindsurf Rules & Cross-IDE-RulesLizenz: MITfrei kopierbar

commit-message-format.md

Zuletzt aktualisiert:

⬇ Als Datei laden

⧉ –× kopiert⬇ –× heruntergeladenBewertung:

Typ

Rule

Lizenz

MIT

Anwendungsfeld

Windsurf Rules & Cross-IDE-Rules

Teams mit Commit-Konventionen

Voraussetzungen

  • Team-Absprache, dass alle Beitragenden diesem Format folgen
  • Git-Repository mit laufender Commit-Historie

Einordnung

AufwandEinrichtung & Einarbeitung2/5 · eher geringNutzenErtrag im Alltag3/5 · mittelVoraussetzungenWas vorher da sein muss1/5 · gering1 = gering5 = hoch

Die Regel selbst ist schnell übernommen, ihr Wert hängt aber davon ab, ob sie im Team konsequent durchgehalten wird.

Commit-Messages nach Conventional Commits (Prefix + Summary + Bullet-Body)

Für wen: Teams mit Commit-Konventionen

Im Detail

Definiert ein Commit-Message-Format auf Basis von Conventional Commits, das über das reine Prefix-Schema hinausgeht: eine kurze englische Zusammenfassung in der ersten Zeile, gefolgt von einem strukturierten Bullet-Body, der einzelne Änderungen auflistet, plus expliziter Sprachkonvention und Regeln für BREAKING CHANGE. Im Vergleich zu kompakteren, emoji-basierten Formatregeln ohne Body-Pflicht liefert diese Regel mehr Detailtiefe für Reviewer, die aus der Historie nachvollziehen wollen, was sich geändert hat. Besonders wertvoll bei Teams mit vielen Beitragenden oder wenn Commits als Dokumentation für spätere Audits dienen.

Schritt für Schritt

  1. Die language-Variable auf die im Projekt tatsächlich verwendete Sprache setzen, falls nicht Englisch
  2. Die Prefix-Liste an die im Projekt üblichen Commit-Typen anpassen, falls zusätzliche Kategorien gebraucht werden
  3. Bei den nächsten Commits prüfen, ob Message dem Schema Prefix, Summary und Bullet-Body entspricht
  4. Stichprobenartig die Git-Historie durchsehen, ob BREAKING CHANGE korrekt markiert wird, wenn es vorkommt
  5. Bei Abweichungen die Regel um Beispiele für Grenzfälle präzisieren

Beispiel aus der Praxis

Ein Commit, der einen Übersetzungsfehler behebt und dabei einen ungenutzten Debug-Log entfernt, wird als fix(translation): Resolve incorrect locale fallback mit den Bulletpunkten Fix locale fallback logic und Remove unnecessary debug log output formatiert statt als eine einzige unstrukturierte Zeile.

Praxis-Tipp

Passen Sie den Parameter “language” und die Liste der Prefixe an Ihre Projektkonventionen an, bevor Sie die Regel team-weit übernehmen – die Vorlage ist bewusst als Ausgangsbasis gedacht.

Stolperfallen

Wird die Regel nicht von allen Beitragenden konsequent angewendet, entsteht eine gemischte Historie, die den Vorteil nachvollziehbarer Audits wieder zunichtemacht. Auch die Sprachvorgabe wird leicht vergessen, wenn im Projekt intern nicht auf Englisch kommuniziert wird.

Siehe auch

Lizenz & Quelle

Häufige Fragen.

Muss ich Englisch als Commit-Sprache verwenden?

Nein, die language-Variable ist austauschbar und sollte laut Regel auf die im Projekt tatsächlich verwendete Sprache eingestellt werden.

Wie unterscheidet sich das von einfachen Conventional Commits?

Es ergänzt die Basisformate um einen Pflicht-Bullet-Body und eine explizite Sprachkonvention, was mehr Detailtiefe für Reviewer liefert.

Muss jeder Commit einen BREAKING CHANGE Abschnitt haben?

Nein, dieser ist laut Format optional und wird nur bei entsprechenden Änderungen angegeben.

Inhalt ansehen (commit-message-format.md)
Lade …

Erfahrungen & Kommentare.

Funktioniert der Rule bei Ihnen? Tipps, Stolperfallen, Varianten — teilen Sie es mit der Community.

Lade Kommentare …

Ihre IP-Adresse wird zum Schutz vor Missbrauch gespeichert und nach 14 Tagen automatisch entfernt (Datenschutz).

Passt dazu.

v5.md

Basis-Regelwerk: Task-Klassifizierung (leicht/standard/kritisch), Tool-Nutzung, Antwortstil

MIT♥ –⧉ –