... | ... | @@ -44,7 +44,9 @@ Jede Haupt-/Major-Version besitzt einen eigenen Branch. Je nach Größe des Proj |
|
|
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.
|
|
|
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.
|
|
|
|
|
|
Wichtig: in den Branches `dev` und `master` darf in der `composer.json` keine `version`-Eigenschaft existieren!
|
|
|
|
|
|
### Versions-Branches
|
|
|
|
... | ... | @@ -71,7 +73,7 @@ git checkout -b 1.0 |
|
|
git push origin 1.0
|
|
|
```
|
|
|
|
|
|
### Eine neue Version veröffentlichen (Release)
|
|
|
### Eine neue Major- oder Minor-Version veröffentlichen (Release)
|
|
|
|
|
|
QUIQQER nutzt GitLab als Projektverwaltung. Releases sind in GitLab sehr einfach umzusetzen, daher solltest du auch GitLab als Oberfläche nutzen.
|
|
|
|
... | ... | @@ -87,7 +89,6 @@ Jetzt musst du nur noch ein Tag für deine neue Version anlegen, um dadurch ein |
|
|
|
|
|
* Ö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
|
|
|
* 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`
|
... | ... | @@ -109,21 +110,14 @@ Beispiele dazu findest du z.B. in den [`quiqqer/quiqqer`-Releases](https://dev.q |
|
|
|
|
|
Wenn du alles richtig gemacht hast, taucht das neue Release auf der Release Seite deines Moduls (`Project Overview > Releases`) auf.
|
|
|
|
|
|
### Vorgehen eines Patches
|
|
|
|
|
|
Damit du ein Patch veröffentlichen kannst, ist ein nicht so kompliziertes Vorgehen nötig.
|
|
|
|
|
|
* Wechsel einfach in den Branch in welchem du ein Patch einspielen möchtest. Zum Beispiel im Branch: 1.0
|
|
|
* Spiele dein Patch ein
|
|
|
* Vergiss nicht die Version in der composer.json anzupassen (im Branch!)
|
|
|
* Erstelle ein neuen tag wie oben beschrieben: mit 1.0.1
|
|
|
|
|
|
D.h. im Branch 1.0 werden alle Patches gemacht welche 1.0.* betreffen. Für den Branch 1.1 wären dies also alle Patches für 1.1.*.
|
|
|
|
|
|
*Wichtig: Wenn du neue Versionsbranches erstellst, denke immer daran die composer.json anzupassen. In den dev-dev und dev-master Branches ist in der composer.json **KEINE** Version anzugeben.*
|
|
|
### Einen Patch veröffentlichen/erstellen (z.B. `1.0.x`)
|
|
|
|
|
|
### Kleinere Module
|
|
|
Damit du ein Patch veröffentlichen kannst, ist ein weniger kompliziertes Vorgehen nötig:
|
|
|
|
|
|
Bei kleineren Modulen kann der MINOR Schritt übergangen werden. Anstatt dann 1.0 und 1.1 Branches zu erstellen reicht es wenn ein 1 und 2 oder 3 Branch erstellt wird. Patches werden dann direkt in die MINOR Branches eingespielt.
|
|
|
* Stelle sicher, dass sich die Änderungen deines Patches im `master`-Branch befinden
|
|
|
* Wechsel in den Versions-Branch zu dem du den Patch hinzufügen möchtest (z.B. `git checkout 1.0`)
|
|
|
* Merge den `master`-Branch in den Versions-Branch: `git merge master`
|
|
|
* Während du noch im Versions-Branch bist, aktualisiere die Version in der `composer.json` (z.B. `"version": "1.0.1"`)
|
|
|
* Erstelle wie oben beschrieben einen neuen Tag für den Patch (z.B. `1.0.1`)
|
|
|
|
|
|
Wenn du dir nicht sicher bist welche Vorgehensweise die richtige für dich ist, die MAJOR, MINOR Vorgehensweise ist im Zweifelsfall immer die richtige. |
|
|
\ No newline at end of file |
|
|
*Wichtig: Wenn du neue Versionsbranches erstellst, denke immer daran die composer.json anzupassen. In den dev-dev und dev-master Branches ist in der composer.json **KEINE** Version anzugeben.* |
|
|
\ No newline at end of file |