Conventional Commits sind ein einfacher Standard für Commit-Nachrichten in Git, der ein konsistentes Format für alle Commits vorschlägt. Dies erleichtert die Automatisierung von Aufgaben wie der Versionskontrolle (Versioning), der Changelog-Erstellung und der Rückverfolgung von Änderungen.

Das Format der Conventional Commits besteht aus einer speziellen Struktur der Commit-Nachricht, die typischerweise folgendermaßen aussieht:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Komponenten eines Conventional Commits:

1. Type (Pflichtfeld): Beschreibt die Art der Änderung im Commit. Es gibt standardisierte Typen:

   • feat: Eine neue Funktion oder ein Feature.
   • fix: Eine Fehlerbehebung.
   • docs: Änderungen an der Dokumentation.
   • style: Änderungen am Code-Stil (z. B. Formatierung), die aber die Logik nicht beeinflussen.
   • refactor: Änderungen am Code, die weder Fehler beheben noch Funktionen hinzufügen, aber den Code verbessern.
   • test: Hinzufügen oder Ändern von Tests.
   • chore: Änderungen am Build-Prozess oder an Hilfswerkzeugen, die keinen Einfluss auf den Quellcode haben.

2. Scope (optional): Beschreibt den betroffenen Teil des Codes oder der Anwendung, z. B. ein Modul oder eine Komponente.

   • Beispiel: fix(auth): corrected password hashing algorithm

3. Description (Pflichtfeld): Eine kurze, prägnante Beschreibung der Änderung. Diese sollte in der Gegenwartsform formuliert sein (z. B. „add feature“ statt „added feature“).

4. Body (optional): Eine ausführlichere Beschreibung der Änderung. Dies kann genutzt werden, um mehr Kontext oder technische Details anzugeben.

5. Footer (optional): Hier können Hinweise zu Breaking Changes oder Referenzen zu Issues oder Tickets stehen.

   • Beispiel: BREAKING CHANGE: remove deprecated authentication method

Beispiel einer Commit-Nachricht im Conventional Commit-Format:

feat(parser): add ability to parse arrays

The parser now supports parsing arrays into lists.
This allows arrays to be passed as arguments to methods.

BREAKING CHANGE: Arrays are now parsed differently

Vorteile von Conventional Commits:

• Konsistenz: Ein einheitliches Format für Commit-Nachrichten erleichtert es, den Projektverlauf zu verstehen.
• Automatisierung: Tools können automatisch Versionen erzeugen, Changelogs erstellen und sogar Veröffentlichungen basierend auf Commit-Nachrichten vornehmen.
• Rückverfolgbarkeit: Es wird leichter, den Zweck einer Änderung nachzuvollziehen, insbesondere bei Fehlerbehebungen oder neuen Funktionen.

Conventional Commits sind besonders in Projekten hilfreich, die SemVer (Semantic Versioning) verwenden, da sie es ermöglichen, automatisch neue Versionen basierend auf Commit-Typen zu erstellen.

"Release Please" ist ein Tool von Google, das den Software-Release-Prozess auf GitHub automatisiert. Es erstellt automatisch Changelogs, generiert Release-Pull-Requests (PRs) und aktualisiert Versionsnummern auf Basis der Commit-Historie eines Projekts. Das Tool nutzt Conventional Commits, also standardisierte Commit-Nachrichten (wie feat:, fix: oder feat!: bei Breaking Changes), um zu entscheiden, wie die Version erhöht und die Release-Notizen erstellt werden.

Sobald es eingerichtet ist, läuft es jedes Mal, wenn neue Commits in den Hauptbranch gepusht werden. Dabei wird ein PR erstellt, der den Changelog und die neue Version enthält. Sobald der PR gemergt wird, erfolgt ein offizieller GitHub-Release. Dies vereinfacht den Release-Prozess, da manuelles Versionieren und die Erstellung von Changelogs entfallen. Allerdings übernimmt es nicht das Veröffentlichen in Paketmanagern.

"Release Please" wird häufig als GitHub Action integriert und ist besonders nützlich für kontinuierliche Integrationsumgebungen und die automatische Verwaltung von Releases.