Gitea: 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
Roth (Diskussion | Beiträge)
sopra, sopra17, sopra18
168 Bearbeitungen
Zeile 33: Zeile 33:
{{RefImg|Create_pull_request.png|500px|4|Erstellen eines Merge-Request in Gitea.}}
{{RefImg|Create_pull_request.png|500px|4|Erstellen eines Merge-Request in Gitea.}}
{{RefImg|Merge_pull_request.png|500px|5|Zusammenführen eines pull request in Gitea.}}
{{RefImg|Merge_pull_request.png|500px|5|Zusammenführen eines pull request in Gitea.}}
Im Sopra wird das Spiel auf dem "master" branch entwickelt. Ist ein wöchentlicher Sprint abgeschlossen, müssen die Änderungen die während des Sprints gemacht wurden mit dem "release" branch zusammengeführt werden.
Ein Pull Request fügt Änderungen, die in einem Quell (z.B. master) zu einem Ziel Branch (z.B. release) hinzu.
==== Workflowim Sopra ====
Pull request erstellen. Siehe auch [[Gitea#Abbildung_4|Abbildung 4]]


* Auf der Navigationsleiste des Repository in Gitea auf "Pull-Requests" klicken, oder den Link <code><link_zur_repo_übersicht>/pulls</code> aufrufen.
In Gitea kann man unter "Pull-Requests" einen neuen Pull-request erstellen. Siehe auch [[Gitea#Abbildung_4|Abbildung 4]]
* Klick auf "Neuer Pull-Request", dann auswählen von "Ziel: release", "Pullen von: master".
Jetzt ist der Pull request in Gitea verfügbar. Als nächster Schritt kann man den Pull request zusammenführen. Siehe auch [[Gitea#Abbildung_5|Abbildung 5]]
* Als Titel "Merge work done in sprint01" oder etwas ähnliches sinvolles eintragen.
* Eventuell eine kleine Zusammenfassung der Änderungen in "Verfassen" hinzufügen.
* Rechts unter "Meilenstein" den zugehörigen Sprint wählen.
* Klick auf "Pull-Request erstellen".


Jetzt ist der Pull request in Gitea verfügbar. Als nächster Schritt kann man den Pull request zusammenführen. Siehe auch [[Gitea#Abbildung_5|Abbildung 5]]
Es gibt 3 möglichkeiten einen Pull-Request zusammenzuführen:
 
In Gitea ist standardmäßig '''"Pull-Request zusammenführen"''' ausgewählt, dadurch werden die Commits aus dem Quell (master) in den Ziel (release) Branch durch einen Merge Commit hinzugefügt. Angenomman man hat diese Situation:
 
A---B---C---D---E master
A---B---C release


* Auf der Navigationsleiste des Repository in Gitea auf "Pull-Requests" klicken, oder den Link <code><link_zur_repo_übersicht>/pulls</code> aufrufen.
Also <code>D</code> und <code>E</code> sind neue Commits in master. Nach dem merge hat man dann diese Situation im release Branch.
* Pull-request der zusammengeführt werden soll anklicken.
* Klicken auf "Pull-Request zusammenführen".
* Im sich öffnenden Dialog im ersten Feld "Merge Branch ..." ersetzen durch "Merge work done in Sprint<XX>".
* Klicken auf "Pull-Request zusammenführen". Dadurch werden die Commits aus dem Quell (master) in den Ziel (release) Branch durch einen Merge Commit hinzugefügt.


Fertig.
            D---E
                  \
A---B---C---------F release


'''Exkurs über das mergen''': In Gitea ist standardmäßig "Pull-Request zusammenführen" ausgewählt, die Variante die wir im Sopra verwenden. Es gibt aber auch die Optionen "Rebasen und Mergen" und "Zusammenfassen und Mergen".
Wobei <code>F</code> der Commit mit der Merge Beschreibung in der Commit Message ist. (Was effektiv <code>git merge master --no-ff</code> entspricht).


Bei '''"Rebasen und Mergen"''' werden die Commits aus dem Quell (master) in den Ziel (release) Branch hinzugefügt, ohne einen Merge Commit. Allerdings unterscheidet sich Giteas "rebase" von "git rebase" und es werden neue aber identische Commits erzeugt, die dann andere Hashes haben. Dies würde Konflikte erzeugen wenn der master Branch weiter zum entwickeln genutzt wird, da beim nächsten merge request die eigentlich identischen Comitts als unterschiedlich angesehen werden. Man müsste also jedes mal "master" löschen und neu erstellen.
Bei '''"Rebasen und Mergen"''' werden die Commits aus dem Quell (master) in den Ziel (release) Branch hinzugefügt, ohne einen Merge Commit. Allerdings unterscheidet sich Giteas "rebase" von "git rebase" und es werden neue aber identische Commits erzeugt, die dann andere Hashes haben. Dies würde Konflikte erzeugen wenn der master Branch weiter zum entwickeln genutzt wird, da beim nächsten merge request die eigentlich identischen Comitts als unterschiedlich angesehen werden. Man müsste also jedes mal "master" löschen und neu erstellen.
Nach dem merge hat man dann diese Situation im release Branch.
A---B---C---D'---E' release
Wobei <code>D'</code> und <code>E'</code> identische "neue" Commits sind.


Bei '''"Zusammenfassen und Mergen"''' werden alle Commits der Quelle (master) in einen Commit gepackt und nur dieser an den Ziel Branch (release) angefügt. Es geht also die Granulierung gurch zusammenfassen aller Vorgänger Commits im Ziel Branch (release) verloren.
Bei '''"Zusammenfassen und Mergen"''' werden alle Commits der Quelle (master) in einen Commit gepackt und nur dieser an den Ziel Branch (release) angefügt. Es geht also die Granulierung gurch zusammenfassen aller Vorgänger Commits im Ziel Branch (release) verloren.


Siehe auch [https://help.github.com/en/articles/about-merge-methods-on-github dieser Github Artikel für mehr Information], der das identische verhalten von Github beim Zusammenführen von Merge-Requests beschreibt.
Nach dem merge hat man dann diese Situation im release Branch.
 
A---B---C---F' release
 
Wobei <code>F'</code> die zusammengefassten Änderungen von <code>D</code> und <code>E</code> enthällt.


=== SSH Key hinzufügen ===
=== SSH Key hinzufügen ===
Abgerufen von „https://sopranium.de/Gitea“