Branches und Workflow
#
Der Hauptbranch heißt “main”
Die Entwicklung neuer Features und das BugFixing erfolgt in der Regel auf Feature Branches ausgehend vom main-Branch.
Die Namen der Branches sollen folgendem Schema folgen: änderungsart/bezeichnung/ticketnr. (Ticketnr. ist optional).
Folgende Änderungsarten haben wir vorgesehen: bugfix, feature, chore, refactoring
Branches werden nach dem Mergen gelöscht
Versionierung
#
Die Versionierung orientiert sich am „Semantic Versioning“ orientieren. Die Versionen werden per Tag sichtbar gemacht.
Pushen
#
Die Commits werden mit thematisch umschließenden Pushes ins Repository geschrieben, wobei es nicht Ziel ist, ganze Features in einem Push zu umschließen, sondern Tätigkeiten. Mit der lokalen Entwicklungsumgebung ist eine tägliche Sicherung ins Repository empfehlenswert um Datenverlust zu verhindern.
Definition Of Done
#
Der Author prüft vor dem Stellen eines Pull Request diese Punkte:
der Ziel-Branch wurde unmittelbar vor dem Stellen des Pull Requests in den Feature-Branch gemerged. Es bestehen daher keine Merge-Konflikte.
der Code ist OK
Es gibt keine Linter-Meldungen
der Code folgt unseren Konventionen
die Dokumentation wurde erweitert
Testfälle/Tests liegen vor
bei neuen Funktionen: kurze Beschreibung eines Testfalls zur Aufnahme ins Testprotokoll (sollte sich aus dem Ticket ergeben)
Unit Tests sind erstellt: Test-Dokumentation
funktionaler Test in gebauter Version
gemäß der Beschreibung im Ticket
Cross-Browser (Chrome, Edge, FF) - mobiles Verhalten im Browser emuliert