Hinweise für Entwickler - kitodo/kitodo-production GitHub Wiki

Allgemein

Arbeit in GIT nach dem Forking Workflow
Einhaltung der Coding Guidelines
Zu entwickelnde Features sollten als Issue vor dem Pull-Request bekannt gemacht werden
Fork Branch Hinweise:
Jeder Branch sollte in sich geschlossen sein und nur genau die Änderungen beinhalten, die nötig sind
können zum Bearbeiten eines Features entweder in privaten, persönlichen Forks oder in einem Fork einer GitHub-Organisation durch mehrere Personen durchgeführt werden

In englischer Sprache, Orientierung an bspw. http://chris.beams.io/posts/git-commit/
Commits sollten nur die Änderungen enthalten, die auch in der Commit Nachricht beschrieben sind
Eher viele kleine Commits mit jeweils wenigen Änderungen als wenige, große / umfangreiche Commits

sollten idealerweise von einer anderen Person als dem Ersteller auf GitHub begutachtet (review changes) werden.
müssen zum Zeitpunkt des Merges fehlerfrei integrierbar sein. Konflikte müssen vom Ersteller gelöst werden.

Branch main: Hier findet die Haupt-Entwicklung inklusive neuer Features, Bugfixes, ... statt
Branch X.Y.x: Hier findet die Wartung einer Major-Minor Release Version statt. Bspw. in 4.0.x die Wartung und neue Releases der Version 4.0.x Versionen (bspw. 4.0.1, 4.0.2, ...)

Scrum / Jira Tickets mit Bezug auf Code-Entwicklung sollten nach dem Start des Sprints als Issue auf GitHub veröffentlicht werden. Die JIRA Tickets sollten eine Verlinkung auf das jeweilige Issue in GitHub enthalten.
In die Scrum Planung sollten auch die Reaktionen auf Issues / Commits / Pull-Requests der Scrum-Issues der Community mit einfließen
Issues aus der Community, die vor der Sprint Planung erstellt werden, sollten in der Scrum Planung bedacht werden

--WORK IN PROGRESS--

Hier finden sich Informationen für Entwickler, die an der (Weiter-)Entwicklung von Kitodo.Production 3.x interessiert sind