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

Commits

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