GitWorkflow
TODO
Sopra-Branching
Für das Sopra empfehlen wir ein mit wenig Verwaltungsaufwand und merging verbundenes Vorgehen, in dem die beiden Branches master und dev verwendet werden. Beide branches erfüllen spezielle Rollen:
- dev: die Arbeit jedes Entwicklers wird auf den branch dev gerebased, sodass eine ordentliche lineare Abfloge von Änderungen entsteht.
- master: jede fertige weiterentwicklung des Projekts (z.B.: das Sprintincrement oder die Hausuafgabe) wird auf den master branch gemergt.
Jeder Gruppe ist es überlassen selbst für spezielle Aufgaben mehr Branches zu verwenden, das mergen des wöchentlichen Inkrements in den master branch ist jedoch obligatorisch, da nur dieser im Gruppentreffen und zur Beurteilung der mitarbeit herangezogen wird.
Beispiel
Kurz bevor ein Sprint endet, sollte die Historie also wie folgt aussehen (git log --graph): der master branch wurde seit Ende des lezten Sprints nicht verändert, der dev branch enthält alle Änderungen die im Sprint gemacht wurden.
(HEAD, dev) | * .... - Fixed bug. Everything working. (closes #22) - student03
| |
| * .... - Game object able to move (hardcoded) see #12 - student01
| |
| * .... - Better wildcard texture for game objects - student03
| |
...
| * .... - A nice drawable game object (see #13) - student01
| |
| * .... - Prototype spatial data structure for game objects see #14 - student02
| |
| * .... - Interface for game objects see #14- student01
|/
(master) *Ein Merge überführt die Änderungen aus dem dev branch in den Masterbranch.
(HEAD, dev, master) *
|\
| * .... - Fixed bug. Everything working. (closes #22) - student03
| |
| * .... - Game object able to move (hardcoded) see #12 - student01
| |
| * .... - Better wildcard texture for game objects - student03
| |
...
| * .... - A nice drawable game object (see #13) - student01
| |
| * .... - Prototype spatial data structure for game objects see #14 - student02
| |
| * .... - Interface for game objects see #14- student01
|/
*Im folgenden Sprint wird weiter am dev branch gearbeitet.
