Contributing Guide
Branch-Strategie
- Neue Features immer von
develop abzweigen
- Fertige Features via Merge (no-ff) in
develop
develop → main nur bei einem Release
Commit-Konventionen
Format: type: kurze Beschreibung
| Typ |
Verwendung |
feat |
Neues Feature |
fix |
Bugfix |
chore |
Build, Konfiguration, Abhängigkeiten |
docs |
Dokumentation |
refactor |
Refactoring ohne Funktionsänderung |
security |
Sicherheits-Fix |
Beispiele:
Release-Prozess
develop vollständig und getestet
- CHANGELOG.md aktualisieren (
[Unreleased] → [x.y.z] - YYYY-MM-DD)
- Commit auf
develop, Push
develop → main mergen (no-ff)
- Tag
vx.y.z erstellen und pushen
- Deploy auf Hetzner (siehe Deployment-Guide)
Versionierung
Semantic Versioning: MAJOR.MINOR.PATCH
|
Wann |
| PATCH |
Bugfixes, kleine Anpassungen |
| MINOR |
Neue Features, abwärtskompatibel |
| MAJOR |
Breaking Changes |
Codeberg Remote
i18n-Regel
Neue Texte immer in allen 4 Sprachdateien gleichzeitig erfassen:
Design-Regeln
- Primary Color: Violet (
#7c3aed / bg-violet-700)
- Icons: Flowbite Outline für Navbar/Modals, Fill für Sidebar-Navigation
- Kein Flowbite JS Runtime — alle Interaktionen als Angular Signals
- Touch-Targets: mindestens
p-2 auf Icon-Buttons
- Mobile-first:
grid-cols-1 sm:grid-cols-2, flex-col sm:flex-row
Sicherheits-Checkliste
Vor jedem Merge in develop prüfen: