GitWorkflow: Unterschied zwischen den Versionen

Aus Das Sopra Wiki
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
VisuellWikitext
Langenfeld (Diskussion | Beiträge)
Bürokraten, sopra, sopra17, sopra18, sopradozenten, soprapre17, Administratoren
1.275 Bearbeitungen
Langenfeld (Diskussion | Beiträge)
Bürokraten, sopra, sopra17, sopra18, sopradozenten, soprapre17, Administratoren
1.275 Bearbeitungen
Keine Bearbeitungszusammenfassung
Zeile 6: Zeile 6:
== Sopra-Branching ==
== 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:
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>dev</code>: die Arbeit jedes Entwicklers wird auf den Branch ''dev'' gerebased, sodass eine ordentliche lineare Abfolge von Änderungen entsteht.
* <code>master</code>: die Arbeit jedes Entwicklers wird auf den Branch ''dev'' gerebased, sodass eine ordentliche lineare Abfolge von Änderungen entsteht.
* <code>master</code>: jede fertige Weiterentwicklung des Projekts (z.B.: das Sprintincrement oder die Hausaufgabe) wird auf den ''master'' branch gemerged.
* <code>release</code>: jede fertige Weiterentwicklung des Projekts (z.B.: das Sprintincrement oder die Hausaufgabe) wird auf den ''master'' branch gemerged.


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.
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 ===
=== Tägliche Arbeit Synchronisieren ===
Zeile 22: Zeile 22:


<source>
<source>
*    d030e28 (origin/dev) A Whitty comment (closes #41) - Tina Teststudent
*    d030e28 (origin/master) A Whitty comment (closes #41) - Tina Teststudent
| *  c91275a (HEAD -> dev) A Whitty comment (closes #22) - Benjamin Beispielstudent
| *  c91275a (HEAD -> master) A Whitty comment (closes #22) - Benjamin Beispielstudent
|/
|/
*    f48f012 Created initial Project - ...
*    f48f012 Created initial Project - ...
</source>
</source>


Da Benjamin beim Pushen gewarnt wird, dass seiner lokalen Kopie von <code>dev</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:
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:


<source>
<source>
*    080fe12 (HEAD -> dev) A Whitty comment (closes #22) - Benjamin Beispielstudent  
*    080fe12 (HEAD -> master) A Whitty comment (closes #22) - Benjamin Beispielstudent  
*    d030e28 (origin/dev) A Whitty comment (closes #41) - Tina Teststudent
*    d030e28 (origin/master) A Whitty comment (closes #41) - Tina Teststudent
*    f48f012 Created initial Project - ...
*    f48f012 Created initial Project - ...
</source>
</source>
Zeile 39: Zeile 39:


<source>
<source>
*    080fe12 (HEAD -> dev, origin/dev) A Whitty comment (closes #22) - Benjamin Beispielstudent
*    080fe12 (HEAD -> master, origin/master) A Whitty comment (closes #22) - Benjamin Beispielstudent
*    d030e28 A Whitty comment (closes #41) - Tina Teststudent
*    d030e28 A Whitty comment (closes #41) - Tina Teststudent
*    f48f012 Created initial Project - ...
*    f48f012 Created initial Project - ...
Zeile 46: Zeile 46:
=== Sprint Abschließen ===
=== Sprint Abschließen ===


Kurz bevor ein Sprint endet, sollte die Historie also wie folgt aussehen (<code>git log --decorate --graph --oneline</code>): der ''master'' branch wurde seit Ende des lezten Sprints nicht verändert, der ''dev'' branch enthält alle Änderungen die im Sprint gemacht wurden.
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.


<source>
<source>
| *  .... (HEAD -> dev) Fixed bug. Everything working. (closes #22)  - student03
| *  .... (HEAD -> master) Fixed bug. Everything working. (closes #22)  - student03
| *  .... Game object able to move (hardcoded) see #12 - student01
| *  .... Game object able to move (hardcoded) see #12 - student01
| *  .... Better wildcard texture for game objects - student03
| *  .... Better wildcard texture for game objects - student03
Zeile 57: Zeile 57:
| *  .... Interface for game objects see #14- student01
| *  .... Interface for game objects see #14- student01
|/
|/
*    .... (master) Merged Sprint into Master.
*    .... (release) Merged Sprint into Master.
</source>
</source>


Nachdem alle Aufgaben für den Sprint beendet sind, wird der Inkrement (alles was sich auf ''dev'' befindet) in den ''master'' Branch übertragen. Dazu wird der ''dev'' Branch in den ''master'' Branch gemerged (<code>git checkout master && git merge dev</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:
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:


<source>
<source>
*    .... (HEAD -> dev, master) Merged Sprint2 into Master.
*    .... (HEAD -> master, release) Merged Sprint2 into Release.
|\
|\
| *  .... Fixed bug. Everything working. (closes #22)  - student03
| *  .... Fixed bug. Everything working. (closes #22)  - student03
Zeile 73: Zeile 73:
| *  .... Interface for game objects see #14- student01
| *  .... Interface for game objects see #14- student01
|/
|/
*    .... Merged Sprint into Master.
*    .... Merged Sprint into Release.
</source>
</source>


Im folgenden Sprint wird weiter am ''dev'' Branch gearbeitet [[Kategorie:Code-Beispiele]].
Im folgenden Sprint wird weiter am ''master'' Branch gearbeitet [[Kategorie:Code-Beispiele]].


<source>
<source>
| *  .... First 'Tank'-unit (closes #26)  - student03
| *  .... First 'Tank'-unit (closes #26)  - student03
* |  .... (HEAD -> dev, master) Merged Sprint2 into Master.
* |  .... (HEAD -> master, release) Merged Sprint2 into Release.
|\|
|\|
| *  .... Fixed bug. Everything working. (closes #22)  - student03
| *  .... Fixed bug. Everything working. (closes #22)  - student03
Abgerufen von „https://sopranium.de/GitWorkflow“