GitWorkflow: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| Zeile 2: | Zeile 2: | ||
<ref>[https://git-scm.com/book/de/v2/Git-Branching-Branches-in-a-Nutshell Branching in a Nutshell]</ref> | <ref>[https://git-scm.com/book/de/v2/Git-Branching-Branches-in-a-Nutshell Branching in a Nutshell]</ref> | ||
<ref>https://nvie.com/posts/a-successful-git-branching-model/</ref> | <ref>https://nvie.com/posts/a-successful-git-branching-model/</ref> | ||
<ref>https://www.endoflineblog.com/gitflow-considered-harmful | <ref>https://www.endoflineblog.com/gitflow-considered-harmful</ref>. | ||
== Sopra-Branching == | == Sopra-Branching == | ||
| Zeile 16: | Zeile 15: | ||
=== Tägliche Arbeit Pushen === | === Tägliche Arbeit Pushen === | ||
Jedes mal wenn Sie mit dem remote repository synchronisieren sollten Sie den Befehl <code>git pull --rebase</code> verwenden, um die zwischenzeitlich auf dem Server eingegangenen Commits zu sychronisieren. Wie im [[Git|Gitartikel]] erklärt entspricht dieser Befehl <code>git fetch; git rebase</code>, sodass eine einfach zu lesende lineare History entsteht (beim rebasen, genau wie beim mergen können Konflikte entstehen, die Git nicht automatisch lösen kann und die durch den Benutzer [[Git#Konflikte lösen| gelöst]] werden müssen, bevor das Ergebnis gepusht werden kann). | Jedes mal wenn Sie mit dem remote repository synchronisieren sollten Sie den Befehl <code>git pull --rebase</code> verwenden, um die zwischenzeitlich auf dem Server eingegangenen Commits zu sychronisieren. Wie im [[Git|Gitartikel]] erklärt entspricht dieser Befehl <code>git fetch; git rebase</code>, sodass eine einfach zu lesende und pflegende lineare History entsteht <ref>https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow</ref> (beim rebasen, genau wie beim mergen können Konflikte entstehen, die Git nicht automatisch lösen kann und die durch den Benutzer [[Git#Konflikte lösen| gelöst]] werden müssen, bevor das Ergebnis gepusht werden kann). | ||
=== Am Ende des Sprints === | === Am Ende des Sprints === | ||
Version vom 16. Oktober 2018, 13:42 Uhr
Für Git existieren verschieden Ansätze um Branching sinvoll zur Organisation des Projekts und der Entwicklung zu nutzen [1] [2] [3].
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.
Tägliche Arbeit Pushen
Jedes mal wenn Sie mit dem remote repository synchronisieren sollten Sie den Befehl git pull --rebase verwenden, um die zwischenzeitlich auf dem Server eingegangenen Commits zu sychronisieren. Wie im Gitartikel erklärt entspricht dieser Befehl git fetch; git rebase, sodass eine einfach zu lesende und pflegende lineare History entsteht [4] (beim rebasen, genau wie beim mergen können Konflikte entstehen, die Git nicht automatisch lösen kann und die durch den Benutzer gelöst werden müssen, bevor das Ergebnis gepusht werden kann).
Am Ende des Sprints
Kurz bevor ein Sprint endet, sollte die Historie also wie folgt aussehen (git log --decorate --graph --oneline): 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) Merged Sprint into Master.Nachdem alle Aufgaben für den Sprint beendet sind, wird der Inkement (alles was sich auf dev befindet) in den master branch übergragen. Dazu wird der dev branch in den master branch gemergt (git checkout master && git merge dev) wahlweise kann der merge auch über einen Pull Request in Gitea erledigt werden. Der Ergebnis sollte in beiden Fällen wie folgt aussehen:
* .... - (HEAD -> dev, master) Merged Sprint2 into 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
|
* .... - Merged Sprint1 into Master.Im folgenden Sprint wird weiter am dev branch gearbeitet.
