Projektanweisungen für FEDEO

Git und Commit-Nachrichten

Neue Projektdateien immer gezielt mit git add aufnehmen.
Nach einem abgeschlossenen Arbeitsschritt die eigenen Änderungen committen. Bereits vorhandene Änderungen anderer Aufgaben nicht mitcommitten oder zurücksetzen.
Jede selbst verfasste Commit-Nachricht muss Conventional Commits verwenden: type(scope): Beschreibung. Der Scope ist optional.
fix: für Fehlerkorrekturen (Patch), feat: für neue Funktionen (Minor), perf: für Leistungsverbesserungen (Patch).
docs:, test:, refactor:, build:, ci:, chore:, style: und revert: passend verwenden. Reine Wartungsänderungen lösen standardmäßig kein Release aus; Reverts können einen Patch auslösen.
Inkompatible Änderungen mit ! im Betreff und einem Footer BREAKING CHANGE: Beschreibung und Migrationshinweis markieren (Major). Diese Kennzeichnung niemals weglassen, um einen Versionssprung zu vermeiden.
Beispiele: fix(accounting): validate invoice totals, feat(stock): add inventory transfers, feat(api)!: replace legacy authentication.
Auch selbst verfasste Squash- und Merge-Betreffzeilen entsprechend benennen. Die Release-Auswertung liest die ursprünglichen Commits und überspringt echte Merge-Commits.

dev ist der Entwicklungszweig. Ein Push auf main ist der vom Benutzer gewählte Release-Auslöser; der Gitea-Workflow prüft, baut und veröffentlicht automatisch.
Änderungen regulär auf dem aktuellen Entwicklungszweig committen. Erst bei einem ausdrücklichen Release-/Merge-/Push-Auftrag nach main übernehmen und pushen.
Versionsnummern werden aus den Git-Tags vMAJOR.MINOR.PATCH und den Commit-Nachrichten berechnet. Keine manuellen Release-Commits oder Änderungen an Paketversionen für Backend/Frontend erzeugen.
Vor Release-Arbeiten docs/releases.md lesen. Vorschau: npm ci && npm run release:preview. Prüfungen: npm test && npm run commits:check.
Veröffentlichte Versions-Tags und Images niemals überschreiben oder löschen. Einen fehlgeschlagenen Release anhand der dokumentierten Wiederaufnahme fortsetzen.
Mobile-App und Device-Agent behalten eigene Paketversionen; ihr Stand wird im Release-Manifest dokumentiert. App-Store-Veröffentlichungen haben einen eigenen Auslöser.