Commit-Message-Konvention
Diese Seite definiert die Commit-Message-Konventionen, die in diesem Repository verwendet werden.
Commit-Message-Format
Bitte gib in der Commit-Message-Zeile dein Projekt und optional die Ticketnummer an. Für die grundlegende Commit-Stilsemantik siehe Conventional Commits.
Verwende dieses Format:
<type>(<PROJECT>-<ticket>): <kurze Zusammenfassung>
oder ohne Ticketnummer:
<type>(<PROJECT>): <kurze Zusammenfassung>
Beispiel:
fix(ZMSKVR-1347): handle unpublished relation filtering
chore(ZMS): Abhängigkeiten aktualisieren
Der Git-Hook commit-msg prüft nur die Subject-Zeile. Merge-Commits nutzen automatisch Gits Standard-Subject Merge branch …. Siehe Git-Hooks (Husky) für Einrichtung und Fehlerbehebung.
Pflichtbestandteile
type: Die Art der Änderung. In diesem Repository übliche Werte:
feat: neue Funktion oder Fähigkeitfix: Fehlerbehebungclean: Refactoring/Aufräumen ohne Verhaltensänderungdocs: ausschließlich Dokumentationsänderungchore: Wartung/Abhängigkeiten/Build-Tooling-Änderungen
project: Der Projektkürzel. Erlaubt sind:
ZMSfür das ZMS-ProjektZMSKVRfür das ZMSKVR-ProjektMPDZBSfür das MPDZBS-ProjektMUXDBSfür das MUXDBS-ProjektGHausschließliche Issue-Nachverfolgung in GitHub
ticket number: Optionale Ziffern passend zur Ticket-/Issue-ID (z. B.
ZMSKVR-1347). Die Nummer kann entfallen; dann nur der Projektscope (z. B.chore(ZMS): …).summary: Eine knappe, in der Befehlsform formulierte Aussage zur Absicht der Änderung.
Beispiele
feat(ZMS-123): add scope hint support for office mappingfix(ZMSKVR-123): prevent stale provider visibility cache readsclean(ZMS-123): simplify munich transformer duration merge logicchore(ZMSKVR-123): update vitepress dependenciesdocs(ZMS-123): document sadb visibility decision flowchore(ZMS): main in Feature-Branch mergenclean(GH): veralteten Workflow entfernen
Regulärer Ausdruck
Die vom Hook commit-msg geprüfte Subject-Zeile entspricht:
^(feat|fix|clean|chore|docs)\((ZMS|ZMSKVR|MPDZBS|MUXDBS|GH)(-[0-9]+)?\): .+$
Merge-Commits mit Subject Merge … sind ausgenommen (siehe Git-Hooks (Husky)).
Weitere Hinweise
- Halte die Subject-Zeile auf das „Warum“ bzw. die Absicht fokussiert, nicht auf einen vollständigen Changelog.
- Nutze einen Body, wenn Kontext nötig ist (z. B. Migrationsnotizen, Verhaltensabwägungen oder Rollout-Implikationen).
- Bevorzuge eine logische Änderung pro Commit, damit Reviews und Cherry-Picks sauber bleiben.
- Für reine Dokumentations-Updates verwende den Typ
docs(...).