Gitea: Unterschied zwischen den Versionen
Roth (Diskussion | Beiträge) |
|||
| 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.}} | ||
Ein Pull Request fügt Änderungen, die in einem Quell (z.B. master) zu einem Ziel Branch (z.B. release) hinzu. | |||
In Gitea kann man unter "Pull-Requests" einen neuen Pull-request erstellen. Siehe auch [[Gitea#Abbildung_4|Abbildung 4]] | |||
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 | |||
Also <code>D</code> und <code>E</code> sind neue Commits in master. Nach dem merge hat man dann diese Situation im release Branch. | |||
D---E | |||
\ | |||
A---B---C---------F release | |||
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. | ||
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 === | ||
Version vom 17. April 2019, 12:14 Uhr
Gitea ist ein leichtgewichtiger Git-Service. Es ist ähnlich zu GitHub, Bitbucket, und Gitlab. Gitea ist ein fork von Gogs. Im SoPra wird Gitea zum einen als remote-Repository verwendet zum anderen als Tool zum umsetzen von Scrum (Scrum und Gitea).
Startseite
Auf der Startseite von Gitea (Abildung 1) befindet sich:
- Eine Übersicht über die neuesten Commits und Aktivitäten in Repositories auf die man Zugriff hat (linke Spalte). In diesem Beispiel ausschließlich Repository
sopra-ws18/sopra11 - Eine Übersicht über alle Repositories auf die man Zugriff hat (rechte Spalte).
Drückt man auf einen der Links an der rechten Seite z.B.: sopra-ws18/sopra11, wechselt man auf die Übersichtsseite des Repositories.
Repository Übersicht
Die Repositoryübersicht ist in mehrere Registerkarten unterteilt (Abbildung 2):
- Code: bietet eine Übersicht über das Repository. Es zeigt die aktuelle Version des default Branch (hier
dev). - Issues: zeigt alle Issues im Projekt an. Hier lassen sich auch Labels bearbeiten und Milestones erstellen.
- Pull Requests: zeigt eine Liste von allen Pull Requests die im Repository gestellt wurden.
- Releases: listet Releases auf, die im Projekt erstellt wurden. Releases verbinden einen bestimmten Zustand des Repositories mit einem Titel, einem Text und zusätzlich hochgeladenen Dateien (z.B: einer kompillierten Version des Programms).
- Wiki: erlaubt es jedem Benutzer des Repositories Wiki-Seiten für das Projekt zu erstellen.
Weitere Funktionen
Repository
Das Repository kann über die unter Code angezeigte URL geklont werden (Siehe Abbildung 3 ). Es ist möglich auf Repository über HTTPS (über Username und Passwort des Giteaaccounts) oder per SSH (mit einem SSH-Key) zuzugreifen. Vor- und Nachteile der einzelnen Methoden können im GitBuch nachgelesen werden.
Pull Request
Ein Pull Request fügt Änderungen, die in einem Quell (z.B. master) zu einem Ziel Branch (z.B. release) hinzu.
In Gitea kann man unter "Pull-Requests" einen neuen Pull-request erstellen. Siehe auch Abbildung 4 Jetzt ist der Pull request in Gitea verfügbar. Als nächster Schritt kann man den Pull request zusammenführen. Siehe auch 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
Also D und E sind neue Commits in master. Nach dem merge hat man dann diese Situation im release Branch.
D---E
\
A---B---C---------F release
Wobei F der Commit mit der Merge Beschreibung in der Commit Message ist. (Was effektiv git merge master --no-ff 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.
Nach dem merge hat man dann diese Situation im release Branch.
A---B---C---D'---E' release
Wobei D' und E' 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.
Nach dem merge hat man dann diese Situation im release Branch.
A---B---C---F' release
Wobei F' die zusammengefassten Änderungen von D und E enthällt.
SSH Key hinzufügen
Um dem Git Client Zugriff auf das Repository zu geben, kann man einen SSH-Key zu seinem Account hinzufügen. Dazu öffnet man https://sopragit.informatik.uni-freiburg.de/user/settings/keys und klickt auf SSH-Schlüssel verwalten. Jetzt kann man den öffentlichen Teil des Schlüssels eintragen und mit Klick auf Schlüssel hinzufügen dem Account hinzufügen.
