Gitea: Unterschied zwischen den Versionen

Aus Das Sopra Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
(14 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Gitea''' ist ein leichtgewichtiger Git-Service. Es ist ähnlich zu GitHub, Bitbucket, und Gitlab. Gitea ist ein [https://blog.gitea.io/2016/12/welcome-to-gitea/ fork von Gogs]. Im SoPra wird Gitea zum einen als [[Git#Remote|remote-Repository]] verwendet zum anderen als [[Scrum und Gitea|Tool zum umsetzen von Scrum (Scrum und Gitea)]].
'''Gitea''' ist ein leichtgewichtiger Git-Service. Es ist ähnlich zu GitHub, Bitbucket, und Gitlab. Gitea ist ein [https://blog.gitea.io/2016/12/welcome-to-gitea/ fork von Gogs]. Im SoPra wird Gitea zum einen als [[Git#Remote|remote-Repository]] verwendet zum anderen als [[Scrum und Gitea|Tool zum Umsetzen von Scrum (Scrum und Gitea)]].
__TOC__
__TOC__


Zeile 9: Zeile 9:
* Eine Übersicht über alle Repositories auf die man Zugriff hat (rechte Spalte).
* Eine Übersicht über alle Repositories auf die man Zugriff hat (rechte Spalte).


Drückt man auf einen der vielen Links an der rechten Seite z.B.: <code>sopra-ws18/sopra11</code>, wechselt man auf die[[Gitea#Repository Übersicht| Übersichtsseite des Repositories]].
Drückt man auf einen der Links an der rechten Seite z.B.: <code>sopra-ws18/sopra11</code>, wechselt man auf die[[Gitea#Repository Übersicht| Übersichtsseite des Repositories]].
<br clear="all">
<br clear="all">


Zeile 16: Zeile 16:


Die Repositoryübersicht ist in mehrere Registerkarten unterteilt (Abbildung 2):
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 <code>dev</code>).  
* '''Code''': bietet eine Übersicht über das Repository. Es zeigt die aktuelle Version des default Branch (hier <code>dev</code>).
* Issues: zeigt alle Issues im Projekt an. Hier lassen sich auch Labels bearbeiten und Milestones erstellen.
* '''Issues''': zeigt alle Issues im Projekt an. Hier lassen sich auch Labels bearbeiten und Milestones erstellen.
* Pull Requests: zeigt eine Liste von allen [https://en.wikipedia.org/wiki/Distributed_version_control#Pull_requests Pull Requests] die im Repository gestellt wurden.
* '''Pull Requests''': zeigt eine Liste von allen [https://en.wikipedia.org/wiki/Distributed_version_control#Pull_requests 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).
* '''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.
* '''Wiki''': erlaubt es jedem Benutzer des Repositories Wiki-Seiten für das Projekt zu erstellen.
<br clear="all">
<br clear="all">


Zeile 28: Zeile 28:
=== Repository ===
=== Repository ===
{{RefImg|gitea_repoUrl.png|500px|3|Die Repositoryansicht von Gitea. Die Rote Box markiert die URL des Repositories zum Klonen.}}
{{RefImg|gitea_repoUrl.png|500px|3|Die Repositoryansicht von Gitea. Die Rote Box markiert die URL des Repositories zum Klonen.}}
Das Repository kann über die unter <code>Code</code> angezeigte URL [[Git#Repository clonen|geklont]] werden (Siehe [[Gitea#Abbildung_3|Abbildung 3]] ). Es ist möglich auf Repository über HTTPS (über Username und Passwort des Giteaaccounts) oder per SSH (mit einem [[Gitea#SSH Key hinzufügen| SSH-Key]]) zuzugreifen. Vor- und Nachteile der einzelnen Methoden können im [https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols GitBuch] nachgelesen werden.
Das Repository kann über die unter <code>Code</code> angezeigte URL [[Git#Repository clonen|geklont]] werden (Siehe [[Gitea#Abbildung_3|Abbildung 3]] ). Es ist möglich auf Repository über HTTPS (über Username und Passwort des [[Gitea#HTTPS Kennwort einrichten|Giteaaccounts]]) oder per SSH (mit einem [[Gitea#SSH Key hinzufügen| SSH-Key]]) zuzugreifen. Vor- und Nachteile der einzelnen Methoden können im [https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols GitBuch] nachgelesen werden.


=== Pull Request ===
=== Pull Request ===
{{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.
Es gibt 3 möglichkeiten einen Pull-Request zusammenzuführen:
* Rechts unter "Meilenstein" den zugehörigen Sprint wählen.
 
* Klick auf "Pull-Request erstellen".
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:


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]]
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.
 
== Auf das Repository zugreifen ==
Sie können auf die folgenden zwei Arten auf ihr Git-Repository zugreifen, indem Sie in Gitea ihren SSH-Key hinterlegen und sich über SSH verbinden oder indem Sie in Gitea ein Gitea-Passwort einrichten (zusätzlich zum Sopra-Account) und sich per HTTPS mit verbinden.


=== SSH Key hinzufügen ===
=== 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.
Um dem Git Client Zugriff via SSH auf das Repository zu geben, kann man einen SSH-Key zu seinem Account hinzufügen. Dazu öffnet man [https://git.sopranium.de/user/settings/keys die Einstellungen unter 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.
 


=== HTTPS Kennwort einrichten ===
Da wir eine zentrale Authentifizierung verwenden, kennt Gitea normalerweise Ihr Passwort nicht. Um ein Repository über HTTPS ansprechen zu können müssen Sie daher ein Passwort in Gitea hinterlegen. Dazu müssen Sie ihr Gitea Account Passwort zurücksetzen. Gehen Sie dazu in [https://git.sopranium.de/user/settings/account die Einstellungen unter Account] und klicken Sie dort auf den Link "Passwort vergessen?". Das System wird Ihnen dann eine Email senden in der sich ein Link befindet mit dem Sie Ihr Gitea-Passwort setzen können. Mit diesem Passwort können Sie dann per Git-Client [[Git#Repository klonen|auf ihr Git-Repository zugreifen]].
[[Kategorie:Begriffe]]
[[Kategorie:Begriffe]]
[[Kategorie:Tutorials]]
[[Kategorie:Tutorials]]
[[Kategorie:Entwurf]]
[[Kategorie:Entwurf]]
[[Kategorie:MS01]]
[[Kategorie:MS01]]

Version vom 13. Oktober 2021, 17:18 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

Abbildung 1: Die Startseite von Gitea.

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

Abbildung 2: Die Repositoryansicht von Gitea.

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

Abbildung 3: Die Repositoryansicht von Gitea. Die Rote Box markiert die URL des Repositories zum Klonen.

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

Abbildung 4: Erstellen eines Merge-Request in Gitea.
Abbildung 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 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.

Auf das Repository zugreifen

Sie können auf die folgenden zwei Arten auf ihr Git-Repository zugreifen, indem Sie in Gitea ihren SSH-Key hinterlegen und sich über SSH verbinden oder indem Sie in Gitea ein Gitea-Passwort einrichten (zusätzlich zum Sopra-Account) und sich per HTTPS mit verbinden.

SSH Key hinzufügen

Um dem Git Client Zugriff via SSH auf das Repository zu geben, kann man einen SSH-Key zu seinem Account hinzufügen. Dazu öffnet man die Einstellungen unter 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.

HTTPS Kennwort einrichten

Da wir eine zentrale Authentifizierung verwenden, kennt Gitea normalerweise Ihr Passwort nicht. Um ein Repository über HTTPS ansprechen zu können müssen Sie daher ein Passwort in Gitea hinterlegen. Dazu müssen Sie ihr Gitea Account Passwort zurücksetzen. Gehen Sie dazu in die Einstellungen unter Account und klicken Sie dort auf den Link "Passwort vergessen?". Das System wird Ihnen dann eine Email senden in der sich ein Link befindet mit dem Sie Ihr Gitea-Passwort setzen können. Mit diesem Passwort können Sie dann per Git-Client auf ihr Git-Repository zugreifen.