# 📘 Commit-Konventionen – Conventional Commits

Dieses Projekt verwendet das [Conventional Commits](https://www.conventionalcommits.org)-Format für einheitliche und nachvollziehbare Commit-Nachrichten.

---

## 🔧 Format

```
<type>[optional scope]: <beschreibung>
```

**Beispiel:**

```
feat: add Ansible deploy playbook
```

- **Englisch**
- **Präsens** (z. B. „add“, nicht „added“)
- **Keine abschließenden Punkte**
- **Optionaler Body** bei größeren Änderungen

---

## 📦 Commit-Typen

| Typ        | Beschreibung                                           |
|------------|--------------------------------------------------------|
| `feat`     | ✨ Neues Feature                                        |
| `fix`      | 🐛 Fehlerbehebung                                      |
| `docs`     | 📘 Nur Dokumentation (z. B. README, .env.example)      |
| `style`    | 🎨 Formatierung, keine Änderung am Verhalten           |
| `refactor` | 🔁 Code-Umstrukturierung ohne neues Verhalten/Feature  |
| `test`     | 🧪 Tests hinzufügen oder anpassen                      |
| `chore`    | 🔧 Projektpflege (z. B. `.gitignore`, `.mailmap`, Cleanup) |

---

## ✅ Gute Commit-Beispiele

```bash
chore: initial commit with Docker + Ansible setup
feat: add restart task to deploy role
fix: correct Docker volume path
docs: add .env.example as reference
chore: add .mailmap to unify author identity
```

---

## 🛑 Vermeide unklare Messages wie:

```bash
"update"
"bugfixes"
"misc"
"more changes"
```

Diese helfen später weder dir noch Tools oder anderen.

---

## 🧠 Tipps

- Nutze aussagekräftige, prägnante Beschreibungen
- Schreibe deine Commits so, dass man daraus verstehen kann, **was passiert** – ohne Git-Diff zu lesen
- Wenn du mehrere Dinge in einem Commit machst, überlege, ob es **mehrere Commits** sein sollten

---

## 📚 Weitere Infos

- [conventionalcommits.org](https://www.conventionalcommits.org)
- [semantic-release](https://semantic-release.gitbook.io/semantic-release/) – für automatische Releases basierend auf Commit-Typen