GitWorkflow: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
KKeine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| (20 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
Für Git existieren verschieden Ansätze um Branching | Für Git existieren verschieden Ansätze um Branching sinnvoll zur Organisation des Projekts und der Entwicklung zu nutzen | ||
<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> | ||
| Zeile 6: | Zeile 6: | ||
== Sopra-Branching == | == Sopra-Branching == | ||
Für das Sopra empfehlen wir ein mit wenig Verwaltungsaufwand und | Für das Sopra empfehlen wir ein mit wenig Verwaltungsaufwand und Merging verbundenes Vorgehen, in dem die beiden Branches ''master'' und ''release'' verwendet werden. Beide Branches erfüllen spezielle Rollen: | ||
* | * <code>master</code>: die Arbeit jedes Entwicklers wird auf den Branch ''master'' gerebased, sodass eine ordentliche lineare Abfolge von Änderungen entsteht. | ||
* | * <code>release</code>: jede abgeschlossene Weiterentwicklung des Projekts (z.B.: das Sprintinkrement oder die Hausaufgabe) wird auf den ''release'' Branch gemerged. Der <code>release</code>-branch repräsentiert zu jeder Zeit einen auslieferbaren Stand des Projektes. | ||
Jeder Gruppe ist es überlassen selbst für spezielle Aufgaben mehr Branches zu verwenden, das Mergen des wöchentlichen Inkrements in den ''release'' branch ist jedoch obligatorisch, da nur dieser im Gruppentreffen und zur Beurteilung der Mitarbeit herangezogen wird. | |||
=== Tägliche Arbeit synchronisieren === | |||
< | 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 synchronisieren. 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 weitergearbeitet werden kann). | ||
* .... - (HEAD -> | |||
| | ==== Beispiel ==== | ||
* .... | |||
| | [[Hausaufgabe#Aufgabe 4: Texte lesen| Aufagbe 4]] der Hausaufgabe erfordert, dass alle Studenten einen Commit pushen. Im unten gezeigten Beispiel hat Studentin Tina ihre Änderung gepusht, nachdem Benjamin sein Repository geklont hatte (d.h. Benjamin hat ihren Commit <code>d030e28</code> nicht in seinem lokalen Repository). | ||
* .... | |||
<pre> | |||
* d030e28 (origin/master) A Whitty comment (closes #41) - Tina Teststudent | |||
| * c91275a (HEAD -> master) A Whitty comment (closes #22) - Benjamin Beispielstudent | |||
|/ | |||
* f48f012 Created initial Project - ... | |||
</pre> | |||
Da Benjamin beim Pushen gewarnt wird, dass seiner lokalen Kopie von <code>master</code> Commits fehlen, die im remote repository vorhanden sind. Benjamin führt <code>git pull --rebase</code> aus. Die lokale Historie sieht nun wie folgt aus, Commit <code>c91275a</code> wurde hinter <code>d030e28</code> gehängt: | |||
<pre> | |||
* 080fe12 (HEAD -> master) A Whitty comment (closes #22) - Benjamin Beispielstudent | |||
* d030e28 (origin/master) A Whitty comment (closes #41) - Tina Teststudent | |||
* f48f012 Created initial Project - ... | |||
</pre> | |||
Benjamin führt nun einen Push aus um seine Änderungen mit dem Server zu synchronisieren. | |||
<pre> | |||
* 080fe12 (HEAD -> master, origin/master) A Whitty comment (closes #22) - Benjamin Beispielstudent | |||
* d030e28 A Whitty comment (closes #41) - Tina Teststudent | |||
* f48f012 Created initial Project - ... | |||
</pre> [[Kategorie:Code-Beispiele]] | |||
=== Sprint abschließen === | |||
Kurz bevor ein Sprint endet, sollte die Historie also wie folgt aussehen (<code>git log --decorate --graph --oneline</code>): der ''release'' branch wurde seit Ende des lezten Sprints nicht verändert, der ''master'' branch enthält alle Änderungen die im Sprint gemacht wurden. | |||
<pre> | |||
| * .... (HEAD -> 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 | ||
| | |/ | ||
* .... | * .... (release) Merged Sprint into Master. | ||
| | </pre> | ||
* .... | |||
</ | |||
Nachdem alle Aufgaben für den Sprint beendet sind, wird der | Nachdem alle Aufgaben für den Sprint beendet sind, wird der Inkrement (alles was sich auf ''master'' befindet) in den ''release'' Branch übertragen. Dazu wird der ''master'' Branch in den ''release'' Branch gemerged (<code>git checkout release && git merge master</code>). Wahlweise kann der Merge auch über einen [[Gitea#Pullrequest| Pull Request in Gitea]] erledigt werden. Der Ergebnis sollte in beiden Fällen wie folgt aussehen: | ||
< | <pre> | ||
* .... | * .... (HEAD -> master, release) Merged Sprint2 into Release. | ||
| | |\ | ||
* .... | | * .... 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 Sprint into Release. | ||
| | </pre> | ||
* .... | |||
</ | Im folgenden Sprint wird weiter am ''master'' Branch gearbeitet [[Kategorie:Code-Beispiele]]. | ||
<pre> | |||
| * .... First 'Tank'-unit (closes #26) - student03 | |||
* | .... (HEAD -> master, release) Merged Sprint2 into Release. | |||
|\| | |||
| * .... Fixed bug. Everything working. (closes #22) - student03 | |||
... | |||
</pre> | |||
== Links == | == Links == | ||
| Zeile 65: | Zeile 95: | ||
== References == | == References == | ||
<references /> | <references /> | ||
[[Kategorie:Organisation]] | |||
Aktuelle Version vom 9. November 2020, 15:00 Uhr
Für Git existieren verschieden Ansätze um Branching sinnvoll 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 release verwendet werden. Beide Branches erfüllen spezielle Rollen:
master: die Arbeit jedes Entwicklers wird auf den Branch master gerebased, sodass eine ordentliche lineare Abfolge von Änderungen entsteht.release: jede abgeschlossene Weiterentwicklung des Projekts (z.B.: das Sprintinkrement oder die Hausaufgabe) wird auf den release Branch gemerged. Derrelease-branch repräsentiert zu jeder Zeit einen auslieferbaren Stand des Projektes.
Jeder Gruppe ist es überlassen selbst für spezielle Aufgaben mehr Branches zu verwenden, das Mergen des wöchentlichen Inkrements in den release branch ist jedoch obligatorisch, da nur dieser im Gruppentreffen und zur Beurteilung der Mitarbeit herangezogen wird.
Tägliche Arbeit synchronisieren
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 synchronisieren. 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 weitergearbeitet werden kann).
Beispiel
Aufagbe 4 der Hausaufgabe erfordert, dass alle Studenten einen Commit pushen. Im unten gezeigten Beispiel hat Studentin Tina ihre Änderung gepusht, nachdem Benjamin sein Repository geklont hatte (d.h. Benjamin hat ihren Commit d030e28 nicht in seinem lokalen Repository).
* d030e28 (origin/master) A Whitty comment (closes #41) - Tina Teststudent | * c91275a (HEAD -> master) A Whitty comment (closes #22) - Benjamin Beispielstudent |/ * f48f012 Created initial Project - ...
Da Benjamin beim Pushen gewarnt wird, dass seiner lokalen Kopie von master Commits fehlen, die im remote repository vorhanden sind. Benjamin führt git pull --rebase aus. Die lokale Historie sieht nun wie folgt aus, Commit c91275a wurde hinter d030e28 gehängt:
* 080fe12 (HEAD -> master) A Whitty comment (closes #22) - Benjamin Beispielstudent * d030e28 (origin/master) A Whitty comment (closes #41) - Tina Teststudent * f48f012 Created initial Project - ...
Benjamin führt nun einen Push aus um seine Änderungen mit dem Server zu synchronisieren.
* 080fe12 (HEAD -> master, origin/master) A Whitty comment (closes #22) - Benjamin Beispielstudent * d030e28 A Whitty comment (closes #41) - Tina Teststudent * f48f012 Created initial Project - ...
Sprint abschließen
Kurz bevor ein Sprint endet, sollte die Historie also wie folgt aussehen (git log --decorate --graph --oneline): der release branch wurde seit Ende des lezten Sprints nicht verändert, der master branch enthält alle Änderungen die im Sprint gemacht wurden.
| * .... (HEAD -> 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 |/ * .... (release) Merged Sprint into Master.
Nachdem alle Aufgaben für den Sprint beendet sind, wird der Inkrement (alles was sich auf master befindet) in den release Branch übertragen. Dazu wird der master Branch in den release Branch gemerged (git checkout release && git merge master). Wahlweise kann der Merge auch über einen Pull Request in Gitea erledigt werden. Der Ergebnis sollte in beiden Fällen wie folgt aussehen:
* .... (HEAD -> master, release) Merged Sprint2 into Release. |\ | * .... 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 Sprint into Release.
Im folgenden Sprint wird weiter am master Branch gearbeitet .
| * .... First 'Tank'-unit (closes #26) - student03 * | .... (HEAD -> master, release) Merged Sprint2 into Release. |\| | * .... Fixed bug. Everything working. (closes #22) - student03 ...
