karolinakita-ux/portfolio

Eine Änderung auf develop ausliefern

Jeder Commit ist eine Version. Regeln in CONTRIBUTING.md ("Jeder Commit"); die Kurzform:

1. Verifizieren. yarn verify (Typecheck, Lint ohne Warnungen, Prettier-Prüfung, Tests, Build mit Pre-Render). Korrigiere den Code, nicht die Regeln: Eine Ausnahme von der Regel ist eine einzeilige Deaktivierung mit einem Grund nach --.
2. Baum prüfen. git status. Der Benutzer könnte unfertige Änderungen haben: Liste nur die von dieser Änderung betroffenen Dateien auf. Lass alles andere ungestaged.
3. Version direkt vor dem Commit wählen (lies version in package.json und den obersten Eintrag in CHANGELOG.md jetzt, nicht früher):
   • major: entfernte oder umbenannte Seiten, geänderte URLs, ein Redesign
   • minor: neue sichtbare Inhalte oder Funktionen
   • patch: Fehlerbehebungen, Text, Bilder, Styling, Abhängigkeiten, Konfiguration, Tests, Dokumentation
4. Changelog. Füge ### X.Y.Z - YYYY-MM-DD unter der einzelnen Überschrift ## Unreleased ein (nach einer Veröffentlichung ist diese verschwunden: füge sie oberhalb der neuesten ## Release ein), mit den Gruppen Hinzugefügt / Geändert / Behoben / Entfernt, jeweils eine kurze Zeile, nur kurze Trennstriche.
5. Commite die aufgelisteten Dateien namentlich: git commit -- <files> mit dem Betreff <was geändert wurde, imperativ> (X.Y.Z), einem kurzen Body und dem Co-Author-Trailer, wenn Claude den Code geschrieben hat.
6. Commit prüfen gegen seine Nachricht: git show --stat HEAD. Dann push auf develop.

Liste vor dem Commiten jede geänderte Einheit (Datei, Funktion, Branch) neben dem Test, der sie abdeckt, auf. Ein ungetesteter Branch erhält einen neuen Test oder einen Hinweis in der Antwort.