Conventional Commits anwenden
Disclaimer
Die Conventional Commits sind ein Standard zur einheitlichen Benennung von Commit-Nachrichten. Sie helfen Teams, Versionsänderungen besser nachzuvollziehen, automatisch Changelogs zu generieren und semantische Versionierung zu automatisieren.
Weitere Informationen: conventionalcommits.org
Was spricht dafür?
- Erleichtert die automatische Generierung von Changelogs
- Unterstützt die semantische Versionierung vom Projekt
- Fördert ein einheitliches und verständliches Commit-Format im Team
- Verbessert die Zusammenarbeit zwischen Entwicklern, Release-Automatisierungstools und CI/CD-Systemen
Anwendungsformat
Ein konformer Commit folgt diesem Format:
Typ(optionaler Scope): Beschreibung
Beispiel:
feat(auth): added login functionality
Commit-Typen
- feat: Fügt eine neue Funktion hinzu (führt zu einem
minor
-Version-Sprung bei semantischer Versionierung) - fix: Behebt einen Bug (führt zu einem
patch
-Version-Sprung) - docs: Änderungen an der Dokumentation (z. B. README, Kommentare)
- style: Formatierungsänderungen (keine Code-Logik-Änderungen, z. B. Einrückung, Leerzeichen, Semikolon)
- refactor: Codeänderungen ohne Fehlerbehebung oder neue Funktion (z. B. Umstrukturierung)
- perf: Leistungsverbesserungen (Performance-Optimierungen)
- test: Hinzufügen oder Anpassen von Tests
- chore: Wartungsaufgaben, die nichts mit dem Quellcode oder Tests zu tun haben (z. B. Build-Prozess, Abhängigkeiten)
Optional: Scope
Der Scope beschreibt, auf welchen Teil der Codebasis sich der Commit bezieht. Er steht in Klammern direkt hinter dem Typ.
Beispiel:
fix(api): resolved error when fetching user data
Breaking Changes
Für Änderungen, die inkompatibel zur bisherigen API sind, wird BREAKING CHANGE:
in der Fußzeile des Commits verwendet.
feat(auth): added two-factor authentication
BREAKING CHANGE: login process has been restructured