Hinweise für Entwickler

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.

Unterscheidung bezieht sich auf die GitHub Projekte Kitodo.ContentServer, Kitodo.Production und Kitodo.UGH
Branch 2.x: ist die Weiterentwicklung der alten Goobi.Production Community Edition (Version 1.11.x) unter dem neuen Namen Kitodo.Production und wird als Version 2.x weiter geführt
Branch master: die unter dem DFG Projekt geförderten Weiterentwicklung von Kitodo.Production findet hier statt und enthält auch die darauf basierenden betriebenen Entwicklungen

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