Gitea-Workflow aktualisiert
parent
0ca704141e
commit
8af6397084
@ -4,21 +4,33 @@ 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.
|
||||
|
||||
Der `main`-Branch ist erreichbar unter:
|
||||
|
||||
- Produktion (`main`): https://itfa.schraubenfuzzi.de
|
||||
|
||||
Der `develop`-Branch stellt den aktuellen Teststand bereit und ist erreichbar unter:
|
||||
|
||||
- Test (`develop`): https://test.itfa.schraubenfuzzi.de
|
||||
(zeigt auf `C:\web\PHP_AdminTool_Projekt_staging`)
|
||||
|
||||
---
|
||||
|
||||
## 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`.
|
||||
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
|
||||
@ -32,7 +44,10 @@ git pull origin main
|
||||
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
|
||||
@ -48,62 +63,168 @@ Wenn du mit deiner Arbeit fertig bist, pushe deinen Branch auf den Gitea-Server.
|
||||
git push -u origin feature/dein-feature-name
|
||||
```
|
||||
|
||||
### Schritt 3: Pull Request in Gitea erstellen
|
||||
---
|
||||
|
||||
## Arbeiten mit dem `develop`-Branch (Testumgebung)
|
||||
|
||||
Bevor ein Feature in `main` gemergt wird, soll es zunächst in der Testumgebung geprüft werden. Dafür verwenden wir den Branch `develop`. Änderungen in `develop` werden auf die Testinstanz unter
|
||||
|
||||
- https://test.itfa.schraubenfuzzi.de
|
||||
|
||||
bereitgestellt.
|
||||
|
||||
Ziele dieses Abschnitts:
|
||||
|
||||
* Entwickler können ihren Code auf dem gemeinsamen Testsystem prüfen.
|
||||
* `develop` dient als technische Integrationsbasis für die Testumgebung.
|
||||
* Feature-Branches werden nach dem Merge in `develop` **nicht** gelöscht.
|
||||
* In `main` landen nur gezielt freigegebene und getestete Features.
|
||||
|
||||
---
|
||||
|
||||
### Schritt A: Pull Request von Feature-Branch nach `develop`
|
||||
|
||||
Sobald dein Feature bereit ist, auf dem Testsystem geprüft zu werden, erstellst du einen Pull Request von deinem Feature-Branch nach `develop`.
|
||||
|
||||
Vorgehen:
|
||||
|
||||
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):** `develop`
|
||||
* **Vergleichs-Branch (rechts):** dein Feature-Branch (z.B. `feature/dein-feature-name`)
|
||||
5. Klicke erneut auf **"Neuer Pull-Request"**.
|
||||
|
||||
|
||||
|
||||
6. Fülle die Maske aus:
|
||||
* **Titel:** Ein klarer Titel (z.B. "Feature: User-Login zum Testen in develop").
|
||||
* **Beschreibung:** Kurz beschreiben, was getestet werden soll.
|
||||
|
||||
Für Pull Requests nach `develop` ist in der Regel **kein Reviewer erforderlich**. Sie dienen dazu, deinen Stand auf das gemeinsame Testsystem zu bringen.
|
||||
|
||||
---
|
||||
|
||||
### Schritt B: Selbst-Merge in `develop`
|
||||
|
||||
Da `develop` als Test-Branch verwendet wird, kannst du deinen eigenen Pull Request nach `develop` selbst mergen.
|
||||
|
||||
1. Öffne deinen Pull Request in Gitea.
|
||||
2. Klicke auf den blauen **"Merge"**-Knopf.
|
||||
3. Bestätige den Merge.
|
||||
|
||||
**Wichtig:**
|
||||
Nach dem Merge in `develop` wird dein Feature-Branch **nicht** gelöscht.
|
||||
Du arbeitest weiter in deinem Feature-Branch und nutzt `develop` nur als Ziel für die Testbereitstellung.
|
||||
|
||||
---
|
||||
|
||||
### Schritt C: Testen auf der Testumgebung
|
||||
|
||||
Nach dem Merge nach `develop` steht dein Code auf der Testinstanz unter
|
||||
|
||||
- https://test.itfa.schraubenfuzzi.de
|
||||
|
||||
zur Verfügung.
|
||||
|
||||
Hier prüfst du beispielsweise:
|
||||
|
||||
* Funktioniert das Feature wie erwartet?
|
||||
* Gibt es offensichtliche Fehler oder Seiteneffekte?
|
||||
* Verhält sich die Anwendung konsistent mit anderen Features im Teststand?
|
||||
|
||||
Wenn du Fehler findest:
|
||||
|
||||
1. Nimm die Anpassungen in deinem Feature-Branch vor.
|
||||
2. Committe und pushe die Änderungen.
|
||||
3. Erstelle erneut einen Pull Request **von deinem Feature-Branch nach `develop`**.
|
||||
4. Mergeb den Pull Request erneut selbst.
|
||||
5. Teste wieder auf der Testinstanz.
|
||||
|
||||
Diesen Zyklus wiederholst du, bis dein Feature stabil ist.
|
||||
|
||||
---
|
||||
|
||||
## Feature erfolgreich getestet → Pull Request nach `main`
|
||||
|
||||
Wenn dein Feature auf der Testumgebung stabil läuft und du mit dem Ergebnis zufrieden bist, erstellst du den eigentlichen Pull Request nach `main`. Erst dieser Schritt führt deinen Code in die Produktion (https://itfa.schraubenfuzzi.de).
|
||||
|
||||
Der Feature-Branch bleibt bis zum erfolgreichen Merge in `main` bestehen und wird erst danach aufgeräumt.
|
||||
|
||||
---
|
||||
|
||||
### Schritt 3: Pull Request in Gitea erstellen (Feature-Branch → `main`)
|
||||
|
||||
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"**.
|
||||
1. Gehe in Gitea zu unserem Projekt-Repository.
|
||||
2. Klicke auf den Reiter **"Pull Requests"**.
|
||||
|
||||
|
||||
|
||||
|
||||
3. Klicke auf den blauen Knopf **"Neuer Pull-Request"**.
|
||||
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 **"Neuer Pull-Request"**.
|
||||
4. **Wähle die Branches aus:**
|
||||
* **Basis-Branch (links):** `main` (dort soll es hin).
|
||||
* **Vergleichs-Branch (rechts):** dein Feature-Branch (z.B. `feature/dein-feature-name`).
|
||||
5. Klicke erneut auf **"Neuer Pull-Request"**.
|
||||
|
||||
|
||||
|
||||
|
||||
6. Fülle die Maske aus:
|
||||
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.
|
||||
* **Beschreibung:** Beschreibe kurz, *was* du getan hast und *warum*. Erwähne idealerweise, dass das Feature bereits in `develop` getestet wurde.
|
||||
* **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.
|
||||
|
||||
Dein Reviewer (oder ein Kollege, der den Pull Request 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.
|
||||
1. Nimm die Änderungen lokal in deinem Feature-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.)*
|
||||
### Schritt 5: Mergen (Zusammenführen in `main`)
|
||||
|
||||
|
||||
Sobald dein Pull Request genehmigt wurde, ist er bereit für das Mergen in `main`.
|
||||
|
||||
4. Bestätige den Merge.
|
||||
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.
|
||||
Dein Code ist jetzt in `main`. Dein alter Feature-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. Dies sollte nach dem Merge in `main` durchgeführt werden.
|
||||
2. **Lokal (Dein PC):** Wechsle zurück zu `main`, hole den neuen Stand (inklusive deines Merges) und lösche deinen lokalen Branch.
|
||||
|
||||
```bash
|
||||
# Zurück zu main
|
||||
@ -118,11 +239,15 @@ 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.
|
||||
|
||||
Pull Requests nach `develop` dienen in erster Linie der technischen Bereitstellung auf dem Testsystem und werden in der Regel nicht formal reviewed.
|
||||
Pull Requests nach `main` werden regulär geprüft.
|
||||
|
||||
---
|
||||
|
||||
### Das Ziel eines Reviews
|
||||
|
||||
* **Qualität sichern:** Finden von Bugs oder logischen Fehlern.
|
||||
@ -132,44 +257,52 @@ Deine Rolle als "Reviewer" ist entscheidend für die Qualitätssicherung. Du bis
|
||||
---
|
||||
|
||||
### 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
* **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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user