# Entwickler Themen

Dieser Bereich enthält Anleitungen und Dokumentation für verschiedenste relevante Themen aus dem Alltag als Entwickler.

# Conventional Commits anwenden

### Disclaimer

<span style="white-space:pre-wrap;">Die </span>****Conventional Commits****<span style="white-space:pre-wrap;"> sind</span> ein Standard zur einheitlichen Benennung von Commit-Nachrichten. Sie helfen Teams, Versionsänderungen besser nachzuvollziehen, automatisch Changelogs zu generieren und semantische Versionierung zu automatisieren.

<span style="white-space:pre-wrap;">Weitere Informationen: </span>[conventionalcommits.org](https://www.conventionalcommits.org/en/v1.0.0/#summary)

---

### Die Vorteile

1. Erleichtert die automatische Generierung von Changelogs
2. <span style="white-space:pre-wrap;">Unterstützt die </span>[semantische Versionierung](https://semver.org/)<span style="white-space:pre-wrap;"> vom Projekt</span>
3. Fördert ein einheitliches und verständliches Commit-Format im Team
4. 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****<span style="white-space:pre-wrap;">: Fügt eine neue Funktion hinzu (führt zu einem </span>`<span class="editor-theme-code">minor</span>`-Version-Sprung bei semantischer Versionierung)
- ****fix****<span style="white-space:pre-wrap;">: Behebt einen Bug (führt zu einem </span>`<span class="editor-theme-code">patch</span>`-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

<span style="white-space:pre-wrap;">Für Änderungen, die inkompatibel zur bisherigen API sind, wird </span>`<span class="editor-theme-code">BREAKING CHANGE:</span>`<span style="white-space:pre-wrap;"> in der Fußzeile des Commits verwendet.</span>

```
feat(auth): added two-factor authentication
BREAKING CHANGE: login process has been restructured
```

# Semantische Versionierung anwenden

### Disclaimer

<span style="white-space:pre-wrap;">Die </span>****semantische Versionierung****<span style="white-space:pre-wrap;"> ist ein gängiger Standard in der Softwareentwicklung, um Versionsnummern zu vergeben. Sie macht Änderungen im Code nachvollziehbar, erleichtert den Umgang mit Abhängigkeiten und verbessert die Kommunikation über den Entwicklungsstand.</span>

<span style="white-space:pre-wrap;">Weitere Informationen: </span>[semver.org](https://semver.org/)

---

### Was ist die semantische Versionierung?

Die semantische Versionierung beschreibt ein dreiteiliges Versionsschema:

```
MAJOR.MINOR.PATCH
```

- ****MAJOR****: Inkompatible Änderungen der öffentlichen API
- ****MINOR****: Neue, abwärtskompatible Funktionalitäten
- ****PATCH****: Abwärtskompatible Fehlerbehebungen

---

### Beispiele aus der Praxis

- `<span class="editor-theme-code">1.2.3</span>`: Erste stabile Version, zwei kleinere Feature-Erweiterungen, drei Bugfixes
- `<span class="editor-theme-code">2.0.0</span>`: Führt zu inkompatiblen API-Änderungen, z. B. durch Entfernen oder Umbenennen von Funktionen
- `<span class="editor-theme-code">1.3.0</span>`: Fügt neue Funktionalitäten hinzu, ohne vorhandene zu verändern
- `<span class="editor-theme-code">1.3.1</span>`: Behebt einen Fehler aus der Version 1.3.0

---

### Regeln der semantischen Versionierung

1. <span style="white-space:pre-wrap;">Erhöhe die </span>****MAJOR****-Version bei inkompatiblen API-Änderungen
2. <span style="white-space:pre-wrap;">Erhöhe die </span>****MINOR****-Version bei neuen, abwärtskompatiblen Funktionen
3. <span style="white-space:pre-wrap;">Erhöhe die </span>****PATCH****-Version bei abwärtskompatiblen Bugfixes

---

### Vorabversionen und Build-Metadaten

Zusätzlich können Vorabversionen und Build-Metadaten angegeben werden:

```
1.0.0-alpha
1.0.0-beta+exp.sha.5114f85
```

- ****Vorabversionen:****<span style="white-space:pre-wrap;"> </span>`<span class="editor-theme-code">-alpha</span>`<span style="white-space:pre-wrap;">, </span>`<span class="editor-theme-code">-beta</span>`<span style="white-space:pre-wrap;">, </span>`<span class="editor-theme-code">-rc</span>`<span style="white-space:pre-wrap;"> usw. – für nicht stabile Entwicklungsstände</span>
- ****Build-Metadaten:****<span style="white-space:pre-wrap;"> </span>`<span class="editor-theme-code">+build</span>`<span style="white-space:pre-wrap;"> – zusätzliche Informationen wie Git-Hashes oder Build-Zeitpunkte</span>

---

### Zusammenfassung

- Die semantische Versionierung gibt eine klare Struktur für Versionen vor
- Sie erleichtert das Management von Abhängigkeiten in Projekten
- <span style="white-space:pre-wrap;">Sie wird häufig in Kombination mit </span>[Conventional Commits](https://www.conventionalcommits.org/de/v1.0.0/)<span style="white-space:pre-wrap;"> verwendet</span>