Gitea-Workflow hinzugefügt
parent
e700939de3
commit
4a71e811c1
153
Gitea-Workflow.-.md
Normal file
153
Gitea-Workflow.-.md
Normal file
@ -0,0 +1,153 @@
|
||||
# Unser Gitea Workflow
|
||||
|
||||
Dieser Leitfaden ist in zwei Rollen unterteilt:
|
||||
* **Autoren:** Alle, die Code schreiben und einen Pull Request erstellen.
|
||||
* **Reviewer:** Alle, die Code prüfen und genehmigen.
|
||||
|
||||
---
|
||||
|
||||
## Gitea Workflow für Autoren
|
||||
|
||||
Dies ist der Leitfaden für jeden, der Code schreibt (ein "Autor"), ein Feature hinzufügt oder einen Bug behebt. Dein Ziel ist es, deine Änderungen sicher und geprüft in den `main`-Branch zu bekommen.
|
||||
|
||||
### Die Goldenen Regeln
|
||||
|
||||
1. **Niemals direkt auf `main` pushen.**
|
||||
2. **Ein Task = Ein Branch.**
|
||||
3. **Klare Branch-Namen:** `feature/beschreibung` oder `bugfix/beschreibung`.
|
||||
|
||||
---
|
||||
|
||||
### Schritt 1: Vorbereitung (Synchronisieren und Branchen)
|
||||
Bevor du eine Zeile Code schreibst, stelle sicher, dass du vom aktuellsten Stand des Projekts startest.
|
||||
|
||||
```bash
|
||||
# 1. Zum main-Branch wechseln
|
||||
git switch main
|
||||
|
||||
# 2. Alle Änderungen vom Server holen
|
||||
git pull origin main
|
||||
|
||||
# 3. Deinen neuen Branch erstellen und dorthin wechseln
|
||||
git switch -c feature/dein-feature-name
|
||||
```
|
||||
|
||||
### Schritt 2: Entwickeln (Committen und Pushen)
|
||||
Jetzt bist du in deinem eigenen Branch. Arbeite hier an deiner Aufgabe. Erstelle kleine, logische Commits mit klaren Nachrichten.
|
||||
|
||||
```bash
|
||||
# (Du programmierst, änderst Dateien...)
|
||||
git add .
|
||||
git commit -m "Feature: Login-Formular-Validierung hinzugefügt"
|
||||
```
|
||||
|
||||
Wenn du mit deiner Arbeit fertig bist, pushe deinen Branch auf den Gitea-Server.
|
||||
|
||||
```bash
|
||||
# Beim ersten Push dieses Branches:
|
||||
git push -u origin feature/dein-feature-name
|
||||
```
|
||||
|
||||
### Schritt 3: Pull Request in Gitea erstellen
|
||||
Ein Pull Request ist deine formale Anfrage, deine Änderungen in `main` zu überführen.
|
||||
|
||||
1. Gehe in Gitea zu unserem Projekt-Repository.
|
||||
2. Klicke auf den Reiter **"Pull Requests"**.
|
||||
3. Klicke auf den blauen Knopf **"Neuer Pull Request"**.
|
||||
4. **Wähle die Branches aus:**
|
||||
* **Basis-Branch (links):** Wähle `main` (dort soll es hin).
|
||||
* **Vergleichs-Branch (rechts):** Wähle deinen Branch (z.B. `feature/dein-feature-name`).
|
||||
5. Klicke erneut auf **"Pull Request erstellen"**.
|
||||
6. Fülle die Maske aus:
|
||||
* **Titel:** Ein klarer Titel (z.B. "Feature: User-Login hinzugefügt").
|
||||
* **Beschreibung:** Beschreibe kurz, *was* du getan hast und *warum*.
|
||||
* **Reviewer: (Optional)** Du kannst den Pull Request einem oder mehreren Kollegen direkt zuweisen. Wenn du niemanden auswählst, geht der Pull Request in den allgemeinen Pool und wartet auf eine proaktive Prüfung durch das Team.
|
||||
|
||||
### Schritt 4: Auf Feedback reagieren
|
||||
Dein Reviewer (oder ein Kollege, der den PR proaktiv prüft) wird sich den Code nun ansehen.
|
||||
|
||||
* **Der Reviewer bittet um Änderungen:** Du siehst Kommentare in deinem Pull Request.
|
||||
1. Nimm die Änderungen lokal in deinem Branch vor.
|
||||
2. Erstelle neue Commits (`git commit ...`).
|
||||
3. Pushe deine neuen Commits (`git push`).
|
||||
4. Der Pull Request aktualisiert sich automatisch.
|
||||
* **Der Reviewer genehmigt (approved) den Pull Request:** Gehe zu Schritt 5.
|
||||
|
||||
### Schritt 5: Mergen (Zusammenführen)
|
||||
Sobald dein Pull Request genehmigt wurde, ist er bereit für das Mergen.
|
||||
|
||||
1. Gehe zu deinem Pull Request in Gitea.
|
||||
2. Du siehst den blauen "Merge"-Knopf. Klicke auf den kleinen Pfeil daneben.
|
||||
3. Wähle aus dem Menü die Option **"Squash Commit erstellen"**.
|
||||
*(Warum? Dies fasst alle deine Commits zu einem einzigen, sauberen Commit in `main` zusammen. Das hält unsere Projekthistorie lesbar.)*
|
||||
4. Bestätige den Merge.
|
||||
|
||||
### Schritt 6: Aufräumen
|
||||
Dein Code ist jetzt in `main`. Dein alter Branch wird nicht mehr gebraucht.
|
||||
|
||||
1. **Remote (Gitea):** Direkt nach dem Merge bietet Gitea meist einen Knopf an, um den Remote-Branch zu löschen. Tu dies.
|
||||
2. **Lokal (Dein PC):** Wechsle zurück zu `main`, hole den neuen Stand (inkl. deines Merges) und lösche deinen lokalen Branch.
|
||||
|
||||
```bash
|
||||
# Zurück zu main
|
||||
git switch main
|
||||
|
||||
# Den aktuellen Stand (mit deinem Merge) holen
|
||||
git pull origin main
|
||||
|
||||
# Deinen alten Branch lokal löschen
|
||||
git branch -d feature/dein-feature-name
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Gitea Workflow für Reviewer
|
||||
|
||||
Deine Rolle als "Reviewer" ist entscheidend für die Qualitätssicherung. Du bist das "Vier-Augen-Prinzip" und stellst sicher, dass nur funktionierender und sauberer Code in den `main`-Branch gelangt.
|
||||
|
||||
### Das Ziel eines Reviews
|
||||
|
||||
* **Qualität sichern:** Finden von Bugs oder logischen Fehlern.
|
||||
* **Konsistenz wahren:** Sicherstellen, dass der Code unseren Standards entspricht.
|
||||
* **Wissen teilen:** Feedback ist eine Chance, voneinander zu lernen.
|
||||
|
||||
---
|
||||
|
||||
### Schritt 1: Den Pull Request finden
|
||||
Es gibt zwei Wege, wie ein Pull Request zu dir kommt:
|
||||
|
||||
1. **Direkte Zuweisung:** Ein Autor weist dich direkt als Reviewer zu. Du erhältst eine Benachrichtigung in Gitea (z.B. im Dashboard).
|
||||
2. **Proaktive Prüfung (Falls nicht zugewiesen):** Der Autor hat **keinen** Reviewer zugewiesen. In diesem Fall ist es **Aufgabe aller Reviewer**, regelmäßig im Repository-Reiter **"Pull Requests"** nach offenen Anfragen zu suchen, die noch keinen Reviewer haben.
|
||||
* **Dies ist entscheidend, damit keine Pull Requests übersehen werden.**
|
||||
* Weise dir den Pull Request selbst zu (falls gewünscht) oder beginne direkt mit Schritt 2.
|
||||
|
||||
### Schritt 2: Den Code prüfen
|
||||
Öffne den Pull Request in Gitea. Konzentriere dich auf diese Bereiche:
|
||||
|
||||
1. **Beschreibung:** Verstehst du, *was* der Autor tun wollte? Ist das Ziel klar?
|
||||
2. **Reiter "Geänderte Dateien":** Das ist der Kern deiner Arbeit. Gehe die Änderungen durch.
|
||||
* **Funktioniert das?** Löst der Code das beschriebene Problem?
|
||||
* **Gibt es offensichtliche Fehler?** (z.B. fehlende Fehlerbehandlung).
|
||||
* **Ist der Code verständlich?** Sind Variablen und Funktionen sinnvoll benannt?
|
||||
* **Passt es zum Rest des Projekts?** Hält sich der Code an unsere Architektur?
|
||||
|
||||
### Schritt 3: Feedback in Gitea geben
|
||||
Während du die Dateien prüfst, kannst du direkt Kommentare hinterlassen:
|
||||
|
||||
* Fahre über eine Zeilennummer, die du kommentieren möchtest, und klicke auf das Plus-Symbol (+).
|
||||
* Schreibe dein Feedback.
|
||||
* Wenn du alle Kommentare gesammelt hast, klicke oben auf **"Review abschicken"** (oder "Submit Review").
|
||||
|
||||
### Schritt 4: Den Review abschließen
|
||||
Wenn du deinen Review abschickst, musst du eine Entscheidung treffen:
|
||||
|
||||
* **Option 1: Kommentare (Request Changes)**
|
||||
* **Wann:** Du hast Fragen oder Fehler gefunden, die der Autor beheben *muss*, bevor gemergt werden kann.
|
||||
* **Was passiert:** Der Autor wird benachrichtigt, nimmt deine Änderungen vor und pusht diese. Der Pull Request wartet auf eine erneute Prüfung.
|
||||
|
||||
* **Option 2: Genehmigen (Approve)**
|
||||
* **Wann:** Der Code ist fehlerfrei, verständlich und bereit für den `main`-Branch.
|
||||
* **Was passiert:** Du klickst auf "Approve". Der Pull Request wird als "genehmigt" markiert.
|
||||
|
||||
**Wichtig:** Der Autor des Pull Requests ist (sofern nicht anders vereinbart) anschließend dafür verantwortlich, den Merge durchzuführen, nachdem die Genehmigung erteilt wurde.
|
||||
Loading…
Reference in New Issue
Block a user