Workflow der Kollaboration: Git, GitHub, Pull Requests, ...

Branches

• main: Der main-Branch ist die Hauptentwicklungslinie. Er enthält den aktuellen Stand der Entwicklung und sollte immer lauffähig sein.
• development: Der development-Branch enthält den aktuellen Stand der Entwicklung, der noch nicht in die Produktion übernommen wurde.
• staging: Der staging-Branch enthält den aktuellen Stand der Entwicklung, der in der Testumgebung getestet wird.
• production: Der production-Branch enthält eube stabile Version der Codebase, die aktuell in der Produktion läuft.

Workflow bei der Entwicklung eines neuen Features

1. Branch erstellen: Erstellen eines neuen Branches von development für das Feature, das entwickelt werden soll. Bitte JIRA-Ticketnummer und eine kurze Beschreibung des Features im Branchnamen verwenden, z.B. HER-232-Feature-Name. Befehl: git checkout -b HER-232-Feature-Name
2. Feature entwickeln: Entwickeln und Testen des neuen Features im Branch. Bitte beachten:
   • Regelmäßig committen: Committen der Änderungen in den Branch mit einer aussagekräftigen Commit-Message.
     • Präfix für Commit-Message: JIRA-Ticketnummer
     • Bei Fehlern oder belanglosen Änderungen kann auch git amend verwendet werden. Befehl: git commit --amend -m "HER-232: Beschreibung des Commits" . Befehl: git commit -m "HER-232: Beschreibung des Commits"
   • Development-Branch aktualisieren, wenn der Maintainer (= Blumi) darauf hinweist: Regelmäßiges Pullen des development-Branches und Merge der Änderungen in euren Feature-Branch. Befehl: git pull origin development und git merge development
3. Feature testen: Testen des Features in der lokalen Entwicklungsumgebung. Oberflächlichen Feauture-Test schreiben.
4. (Refactoring): Falls nötig, Refactoring des Codes durchführen.
5. Feature-Branch pushen: Pushen des Feature-Branches in das Remote-Repository. Befehl: git push origin HER-232-Feature-Name
6. (Dokumentation): Falls es ein Feature ist, auf dem weitere Features aufbauen: Dokumentation des Features in den Docs.
7. Pull Request erstellen: Erstellen eines Pull Requests von eurem Feature-Branch in den development-Branch. Ohne Pull-Request kann der Code nicht in die Codebase übernommen werden.
8. Code Review: Der Code wird von einem anderen Entwickler geprüft. Der Reviewer gibt Feedback und der Entwickler passt den Code entsprechend an.
9. Merge des Pull Requests: Der Pull Request wird in development gemerged. Der Feature-Branch wird von mir gelöscht.
10. Aufruf zum Pullen: Alle werden aufgefordert, den development-Branch zu pullen und die aktuellen Änderungen zu mergen.

Workflow bei einem Bugfix

1. JIRA-Ticket erstellen: Erstellen eines JIRA-Tickets für den Bugfix.
2. Branch erstellen: Erstellen eines neuen Branches von development für den Bugfix. Bitte JIRA-Ticketnummer und eine kurze Beschreibung des Bugfixes im Branchnamen verwenden, z.B. HER-232-Bugfix-Name. Befehl: git checkout -b HER-232-Bugfix-Name
3. Bugfix entwickeln: Best Practice: Wegwerf-Tests schreiben, in denen der Bug reproduziert wird. Wenn Test grün, dann ist der Bug behoben. Andernfalls: Manuelle Tests durchführen.
4. Bugfix-Branch pushen + Pull Request erstellen: Wie bei einem Feature-Branch.
5. Auf Aufruf zum Pullen warten: Der Bugfix wird in development gemerged. Der Bugfix-Branch wird von mir gelöscht.

Workflow, wenn der development-Branch aktualisiert wurde

1. Pullen des development-Branches: Pullen des development-Branches und Merge der Änderungen in euren Feature-Branch. Befehl: git pull origin development und git merge development
2. Merge-Konflikte lösen: Falls Merge-Konflikte auftreten, diese manuell lösen. Achtung: Übernehmt die Änderungen aus dem development-Branch nur dann, wenn sie nicht eure Änderungen eurer aktuellen Entwicklung überschreiben.
3. Testen: Testen, ob euer Code noch funktioniert. Falls euer Code nicht mehr funktioniert: (A) Eigenen Code an die neuen Änderungen des development-Branches anpassen. (B) Falls das nicht möglich ist, bitte mich informieren.

Troubleshooting

Möglicherweise kann nach dem Merge eines anderen Branches der PHP-Server oder der Vite Dev-Server nicht gestartet werden, weil neue Packages verlangt werden oder veraltete Packages aus dem Cache geladen werden.

Hier sind einige Schritte, die bei der Fehlerbehandlung helfen können:

• Git-Submodules aktualisieren: Befehl: git submodule update --init --recursive
• PHP-Server neu starten (php artisan serve oder der entsprechenden Umgebung wie Herd, Laragon, etc.)
• Vite-Dev-Server neu starten (npm run dev): Werden Frontend-Fehlermeldungen ausgegeben?
• Caches leeren: Befehl: php artisan cache:clear und php artisan route:clear und php artisan view:clear.
• php artisan optimize ausführen: Werden Fehlermeldungen ausgegeben? Diese können beim Debuggen helfen.
• composer dump-autoload ausführen: Dadurch werden die Autoload-Dateien für PHP-Klassen neu erstellt.
• composer install ausführen: Dadurch werden alle in der composer.json angegebenen PHP-Pakete (neu) installiert. Danach müsste automatisch auch composer dump-autoload ausgeführt werden.
• npm install ausführen: Dadurch werden alle in der package.json angegebenen Frontend-Pakete (neu)installiert.

Folgendes kann überprüft werden, falls es immer noch nicht funktioniert:

• Wird von der neuen App-Version eine ENV-Variable benutzt, die nicht in der .env-Datei hinterlegt ist? In diesem Fall Kontakt mit anderen Entwicklern aufnehmen.
• Ist der Merge wirklich abgeschlossen?
  • Status überprüfen: git status
  • Falls alles zu kompliziert wird und man nochmal von vorne beinnen möchte: git merge --abort: Bringt Repository zurück in den alten Zustand vor dem Merge.
  • Merge wurde durchgeführt, aber Konflikte wurden falsch gelöst und man möchte ddas Merge rückgängig machen: git reset --hard ORIG_HEAD: Setzt die Repository auf den Zustand vor dem Merge zurück; lokale Änderungen nach dem Merge werden verworfen.
  • Falls gar nichts mehr geht und man zu einem bestimmten Commit zurückspringen möchte: git reset --hard [commit-id]´: [commit-id]` ist der Hash des Commits, zu dem man zurückspringen will. ACHTUNG: Alle Commits und Änderungen nach dem gewünschten Commit werden gelöscht!