Ein Changelog ist eine Datei oder ein Dokument, das die Änderungen und Updates an einer Software oder einem Projekt auflistet. Es enthält eine chronologische Aufzeichnung von neuen Funktionen, Fehlerbehebungen, Verbesserungen und Breaking Changes (Änderungen, die die Rückwärtskompatibilität brechen). Ein Changelog hilft Benutzern und Entwicklern, den Entwicklungsverlauf einer Software zu verfolgen und zu verstehen, welche Änderungen in einer bestimmten Version vorgenommen wurden.

Wichtige Bestandteile eines Changelogs:

1. Versionsnummern: Jede Änderung wird mit der entsprechenden Versionsnummer versehen (z. B. 1.2.0), oft basierend auf SemVer (Semantic Versioning).
2. Änderungstypen: Die Änderungen sind in Kategorien eingeteilt, wie:
   • Added: Neue Funktionen oder Features.
   • Changed: Änderungen an bestehenden Funktionen.
   • Fixed: Fehlerbehebungen.
   • Deprecated: Veraltete Funktionen, die in zukünftigen Versionen entfernt werden.
   • Removed: Entfernte Funktionen.
   • Security: Sicherheitsrelevante Verbesserungen oder Patches.
3. Beschreibung der Änderungen: Jede Änderung wird kurz und prägnant beschrieben, oft mit zusätzlichen Details, wenn nötig.

Beispiel eines Changelogs:

# Changelog

## [1.2.0] - 2023-09-19
### Added
- New user authentication system.
- Ability to reset passwords via email.

### Fixed
- Resolved bug with session timeout after 30 minutes of inactivity.

### Changed
- Updated the UI for the login screen.

## [1.1.0] - 2023-08-10
### Added
- New dark mode theme for the dashboard.

### Security
- Patched vulnerability in file upload functionality.

Vorteile eines Changelogs:

• Transparenz: Ein Changelog zeigt klar, was sich von Version zu Version geändert hat.
• Dokumentation: Es dient als nützliches Referenzdokument für Benutzer, die wissen möchten, welche Funktionen oder Fehlerbehebungen in einer neuen Version enthalten sind.
• Rückverfolgbarkeit: Entwickler können anhand des Changelogs frühere Änderungen nachvollziehen, was bei der Fehlersuche oder bei Upgrades wichtig ist.

Changelogs sind in Open-Source-Projekten besonders weit verbreitet, da sie für die Community eine nachvollziehbare und klare Übersicht über die Entwicklung eines Projekts bieten.

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.