Strategie

Wir nutzen GitFlow (opens new window) und Merge Requests (opens new window) basierten Workflow.

Commits

Die Commits sollen in der Summary schon eine Aussagekraft haben. Dies soll über Über Prefixes geschehen:

• add/ => wenn etwas (Dateien/Funktionalität/...) hinzugefügt wurde
• update/ => wenn Bestehendes verändert wurde
• delete/ => wenn etwas Bestehendes gelöscht wurde
• fix/ => wenn etwas Bestehendes repariert wurde
• wip => wenn etwas zwischen gespeichert wird (z.B. zwischen Geräte Wechsel)

Die Commit-Message soll in Stichpunkten geschrieben werden - als Indikator.
Erst soll geschrieben werden, was gemacht wurde, dann ein Trennzeichen ---. Anschließend, wieso es gemacht wurde. Fall es einen betreffenden Issue gibt, ein weiteres Trennzeichen --- und die Issuenummer mit Raute dazu.

Bsp:

update/Dateiupload für PDFs erweitert
---------------------------------------
- erweitert den Dateiupload, sodass er auch .pdf-Formate akzeptiert
---
- Frau Mustermann von Musterunternehmen hatte sich gewünscht auch PDFs hochzuladen
---
- #123

Branches

Ähnlich der Commits gibt es eine bestimmte Namenskonvention, welche über Prefixes funktioniert.
Es darf folgende Branches geben:

• main
  • soll die aktuellste lauffähige (deployte) Version beinhalten
  • in diesen Branch wird nur durch GitFlow gemerged
• dev
  • soll die aktuellste lauffähige Entwicklungsversion enthalten
• staging
  • die aktuelle Version auf der staging Umgebung
  • triggert Builds
• feature/*
  • auf diesem Branch werden Features entwickelt
  • sollte verlinkt zum Issues, indem der Branch direkt aus dem Issue heraus erstellt wird:
  • der Name soll immer die Issuenummer beinhalten/referenzieren

  • feature/#[IssueNummer]_[slug-des-issue-titels]

  • feature/-Branches werden aus dem dev-Branch erstellt
• realease/*
  • hierüber werden die Releases gestartet
  • triggert Builds

  • realease/[Sem.ver.version]

• hotfix/*
  • für Hotfixes, die an dem normalen Release vorbei geschleust werden
  • triggert Builds

  • hotfix/#[IssueNummer]_[slug-des-issue-titels]

Merge Requests

Merge Requests oder auch Pull Requests sind eine Möglichkeit mittels Git das geordnete Implementieren von Features zu realisieren.
MRs sollten immer gegengecheckt werden. Jeder Feature-Branch sollte mittels MR in den dev-Branch gemerged und anschließend gelöscht werden.

⚠️

Bevor der MR gestellt wird, sollte der dev-Branch in den feature/-Branch gemerged werden um Konflikte zu vor zu beugen.
Zusätzlich müssen alle Tests (php artisan test & php artisan dusk) erfolgreich durchlaufen.

übergeordnetes Thema

2.3 Git