... | ... | @@ -39,15 +39,21 @@ Jede Haupt-/Major-Version besitzt einen eigenen Branch. Je nach Größe des Proj |
|
|
|
|
|
## Für Entwickler
|
|
|
|
|
|
### Grundlegende Entwicklungs-Branches (für ein neues QUIQQER Paket)
|
|
|
### Grundlegende Entwicklungs-Branches (`dev` und `master`)
|
|
|
|
|
|
Wenn du als Entwickler ein neues Paket anlegst, sollten die Branches `dev` und `master` direkt zu Anfang angelegt werden. Diese zwei Branches sind die Grundlage für dein neues Repository.
|
|
|
Wenn du als Entwickler ein neues Paket anlegst, sollten die Branches `dev` und `master` direkt zu Anfang angelegt werden. Diese zwei Branches sind die Grundlage für dein neues Repository.
|
|
|
|
|
|
Der Branch `dev` wird für die aktive Entwicklung genutzt und darf instabilen Code enthalten.
|
|
|
Der Branch `master` beinhaltet fertiggestellte Funktionen und Fehlerbehebungen, die stabil sein sollten aber noch ungetestet sein können. Die einzigen Commits auf diesem Branch sollten per Merge aus dem `dev`-Branch erstellt werden, sobald dort etwas fertiggestellt wurde.
|
|
|
|
|
|
### Versions-Branches
|
|
|
|
|
|
Wenn dein `master`-Branch in einem stabilen Zustand und ausreichend getestet ist, kannst du daraus einen Versions-Branch abzweigen. Der Versions-Branches sollte wie folgt benannt werden: `<major version number>.<minor version number>`. Also zum Beispiel: `1.0`, `1.1`, `1.2`, `2.0`.
|
|
|
Wenn dein `master`-Branch in einem stabilen Zustand und vollständig getestet ist, kannst du daraus einen Versions-Branch abzweigen.
|
|
|
|
|
|
Versions-Branches sollten wie folgt benannt werden: `<major version number>.<minor version number>`.
|
|
|
Also zum Beispiel: `1.0`, `1.1`, `1.2` oder `2.0`.
|
|
|
|
|
|
Um einen Versions-Branch per git zu erstellen machst du also folgendes in der Konsole:
|
|
|
Um einen Versions-Branch per git zu erstellen kannst du folgendes Befehle in der Konsole ausführen:
|
|
|
|
|
|
```bash
|
|
|
# Sicherstellen, dass du auf dem master Branch bist
|
... | ... | @@ -63,22 +69,43 @@ git checkout -b 1.0 |
|
|
git push origin 1.0
|
|
|
```
|
|
|
|
|
|
### Vorgehen eines Releases (MAJOR, MINOR)
|
|
|
### Eine neue Version veröffentlichen (Release)
|
|
|
|
|
|
QUIQQER nutzt GitLab als Projektverwaltung. Releases sind in GitLab sehr einfach anzulegen, daher solltest du auch GitLab als Oberfläche nutzen.
|
|
|
QUIQQER nutzt GitLab als Projektverwaltung. Releases sind in GitLab sehr einfach umzusetzen, daher solltest du auch GitLab als Oberfläche nutzen.
|
|
|
|
|
|
Wir gehen in diesem Beispiel davon aus, das die Branches dev-dev und dev-master erstellt sind. Nun hast du deine Änderungen von dev-dev in dev-master gemerged und möchtest dein erstes Release erstellen.
|
|
|
Wir gehen davon aus, das die Branches `dev` und `master` existieren.
|
|
|
Du hast nun deine fertiggestellten Änderungen vom `dev` in den `master`-Branch gemerged und dort sichergestellt, dass alles korrekt funktioniert. Nun kannst du einen neue(n) Release/Version erstellen:
|
|
|
|
|
|
* Hierzu legst du einen neuen Branch 1.0 an. Ausgehend von deinem dev-master Branch.
|
|
|
* Danach wechselst du in den 1.0 Branch und erweiterst deine composer.json um einen Version Eintrag mit Version: “1.0.0“
|
|
|
* Wenn du die Änderungen gemacht hast, pushed du deinen neuen 1.0 Branch
|
|
|
* Lege ausgehend von deinem `master`-Branch einen Versions-Branch - wie oben beschrieben - an
|
|
|
* Wechsle in den Versions-Branch und erweitere die `composer.json` um einen Versions-Eintrag mit deiner gewünschten Version nach dem Muster `<major>.<minor>.<patch>` (also z.B: `"version": "1.0.0"`)
|
|
|
* Commite deine Änderungen an der `composer.json` mit der folgenden Nachricht: `refactor: version <Versionsnummer>`. Also z.B.: `refactor: version 1.0.0`
|
|
|
* Pushe deine Änderungen auf den Versions-Branch: `git push`
|
|
|
|
|
|
Wenn du diese Schritte gemacht hast, musst du nur noch ein Tag 1.0.0 anlegen um dadurch ein Release zu markieren. Hierzu gehst du wie folgt vor:
|
|
|
Jetzt musst du nur noch ein Tag für deine neue Version anlegen, um dadurch ein Release zu markieren. Hierzu gehst du wie folgt vor:
|
|
|
|
|
|
* Auf jeder Projekt Seite findest du ein Plus neben dem Projektnamen. Hier klickst du auf New tag.
|
|
|
* Öffne dein Projekt in GitLab und rufe den Bereich `Repository > Tags` auf
|
|
|
* Klicke (oben rechts) auf den Button `New tag`
|
|
|
* Wichtig ist, fülle bitte alle Felder aus, damit GitLab merkt das dies eine neues Release ist. In unserem Beispiel wäre das 1.0.0
|
|
|
* Danach noch alle Felder ausfüllen und der Tag kann erstellt werden
|
|
|
Wenn du alles richtig gemacht hast, taucht das neue Release auf der Release Seite auf. Zum Beispiel: https://dev.quiqqer.com/quiqqer/package-smarty/-/releases
|
|
|
* Fülle alle Felder wie folgt aus:
|
|
|
* Tag name: deine Versionsnummer - also z.B. `1.0.0`
|
|
|
* Create from: dein Versions-Branch - also z.B. `1.0`
|
|
|
* Message: `refactor: version <deine Versionsnummer>` - also z.B. `refactor: version 1.0.0`
|
|
|
* Release notes: Hier listest du alle neuen Features und Fixes deiner Version (im Markdown-Format) auf. Dazu kannst du die nachfolgende Vorlage nutzen:
|
|
|
```markdown
|
|
|
## Release notes for `<deine Versionsnummer>`
|
|
|
|
|
|
### Features
|
|
|
|
|
|
- <Feature 1>
|
|
|
- <Feature 2>
|
|
|
|
|
|
### Fixes
|
|
|
|
|
|
- <Fix 1>
|
|
|
```
|
|
|
Beispiele dazu findest du z.B. in den [`quiqqer/quiqqer`-Releases](https://dev.quiqqer.com/quiqqer/quiqqer/-/releases/1.4.0)
|
|
|
|
|
|
Wenn du alles richtig gemacht hast, taucht das neue Release auf der Release Seite deines Moduls (`Project Overview > Releases`) auf.
|
|
|
|
|
|
### Vorgehen eines Patches
|
|
|
|
... | ... | |