2.0 KiB
2.0 KiB
📘 Commit-Konventionen – Conventional Commits
Dieses Projekt verwendet das Conventional Commits-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
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:
"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
- semantic-release – für automatische Releases basierend auf Commit-Typen