2.1 KiB
Richtlinien für Beiträge (Contribution Guidelines)
Um eine konsistente und lesbare Git-Historie zu gewährleisten, folgt dieses Projekt der Conventional Commits Spezifikation.
Wichtiger Hinweis: Alle Commit-Nachrichten müssen auf Englisch verfasst werden. Dieses Dokument dient nur dem deutschsprachigen Verständnis der Regeln.
Format der Commit-Nachricht
Jede Commit-Nachricht besteht aus einem Header, einem Body und einem Footer.
<type>[optional scope]: <description>
[optional body]
[optional footer]
Type (Typ)
Der Typ ist eine Kennzeichnung, die am Anfang der Betreffzeile steht und den Inhalt des Commits klassifiziert. Er muss einer der folgenden sein:
- feat: Eine neue Funktion für den Benutzer (a new feature).
- fix: Eine Fehlerbehebung für den Benutzer (a bug fix).
- docs: Änderungen an der Dokumentation.
- style: Änderungen, die die Bedeutung des Codes nicht beeinflussen (Formatierung, Leerräume, fehlende Semikolons usw.).
- refactor: Eine Code-Änderung, die weder einen Fehler behebt noch eine Funktion hinzufügt.
- perf: Eine Code-Änderung, die die Leistung verbessert.
- test: Hinzufügen oder Korrigieren von Tests.
- chore: Änderungen am Build-Prozess oder an Hilfswerkzeugen und Bibliotheken (z.B. Dokumentationsgenerierung).
- build: Änderungen, die das Build-System oder externe Abhängigkeiten betreffen.
- ci: Änderungen an CI-Konfigurationsdateien und Skripten.
Description (Beschreibung)
Die Beschreibung ist eine kurze Zusammenfassung der Code-Änderungen. Sie sollte im Imperativ und Präsens verfasst sein (z.B. "add feature" anstatt "added feature" oder "adds feature").
Breaking Changes (Wichtige Änderungen)
Ein Commit, der eine inkompatible API-Änderung einführt, muss im Footer mit BREAKING CHANGE: beginnen. Ein "BREAKING CHANGE" kann Teil jedes Commit-Typs sein.
Dieses Dokument ist eine Zusammenfassung. Weitere Details finden Sie in der offiziellen Conventional Commits Spezifikation.