Entwicklung erfolgt in Feature-Branches (feature/...) auf Basis von develop.
Feature-Branches werden per Pull Request nach develop gemergt und auf dem Testsystem bereitgestellt.
Nach erfolgreichem Test wird ein Pull Request von develop nach main erstellt.
Änderungen in main werden auf das Produktivsystem ausgerollt.

feature/* → Pull Request nach develop → Testsystem
erfolgreich getestet → Pull Request nach main → Review → Produktion

Die genauen Schritte und Konventionen (Branch-Namen, Reviews, Umgang mit Fehlern) sind im weiteren Verlauf dieser Seite beschrieben.

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

Niemals direkt auf main pushen.
Ein Task = Ein Branch.
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.

# 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.

# (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.

# Beim ersten Push dieses Branches:
git push -u origin feature/dein-feature-name

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:

Gehe in Gitea zu unserem Projekt-Repository.
Klicke auf den Reiter "Pull Requests".
Klicke auf den blauen Knopf "Neuer Pull-Request".
Wähle die Branches aus:
- Basis-Branch (links): develop
- Vergleichs-Branch (rechts): dein Feature-Branch (z.B. feature/dein-feature-name)
Klicke erneut auf "Neuer Pull-Request".
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.

Öffne deinen Pull Request in Gitea.
Klicke auf den blauen "Merge"-Knopf.
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:

Nimm die Anpassungen in deinem Feature-Branch vor.
Committe und pushe die Änderungen.
Erstelle erneut einen Pull Request von deinem Feature-Branch nach develop.
Mergeb den Pull Request erneut selbst.
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.

Gehe in Gitea zu unserem Projekt-Repository.
Klicke auf den Reiter "Pull Requests".
Klicke auf den blauen Knopf "Neuer Pull-Request".
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).
Klicke erneut auf "Neuer Pull-Request".
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. 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 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 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 in `main`)

Sobald dein Pull Request genehmigt wurde, ist er bereit für das Mergen in main.

Gehe zu deinem Pull Request in Gitea.
Du siehst den blauen "Merge"-Knopf. Klicke auf den kleinen Pfeil daneben.
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.)
Bestätige den Merge.

Schritt 6: Aufräumen

Dein Code ist jetzt in main. Dein alter Feature-Branch wird nicht mehr gebraucht.

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.
Lokal (Dein PC): Wechsle zurück zu main, hole den neuen Stand (inklusive deines Merges) und lösche deinen lokalen Branch.

# 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.

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.
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:

Direkte Zuweisung: Ein Autor weist dich direkt als Reviewer zu. Du erhältst eine Benachrichtigung in Gitea (z.B. im Dashboard).
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:

Beschreibung: Verstehst du, was der Autor tun wollte? Ist das Ziel klar?
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.

Unser Gitea Workflow

Kurzüberblick