Branches

Festlegung

• die nachfolgende Beschreibung trifft nur für folgende Projekte zu
• OurplantOS
• Für alles anderen Projekte gibt es nur den master Branch. Dieser ist zugleich Entwickler- und Release- Branch. Merge Requests entfallen. Projekte, die das betrifft, sind z.B.
• Microservices
• Tools
• Packages, etc.

Branch Typen

Branch	Beschreibung	Anmerkung
feature/Issue_Text	Feature Entwickler Branch	- erstellt aus dem develop - Bsp: feature/123_new_feature - Umsetzung von Features, Bugfixes
develop	Hauptentwickler Branch	- kleinere Änderungen - Übersetzungen
master	Release Branch	- Erstellung von Versionen - TAGs werden hier erzeugt
releasenotes	Test Branch für Release Notes	- erstellt aus dem master - Zur Sichtung der Release Notes

• es gibt keine Testversionen mehr
• ein Hotfix ist immer der komplette Stand vom develop Branch zum letzten Release
• ein Release wird intern als Hotfix bezeichnet, wenn es eine Reparatur des Minor Releases darstellt. Es wird die 3. Stelle hochgezählt
• Bsp. Major.Minor.Hotfix
• Release: V3.17.0
• Hotfix: V3.17.1

1. Release Branch

master

• release branch
• Basis für develop, releasenotes Branches
• beinhaltet Tags, die Releasenummern

• dauerhafter Branch

• Erweiterung:

• Wenn ein grosses Release geplant wird, wie z.B. die Umstrukturierung von Kameraservices, ist es möglich ein masterXY Branch als parallel Branch zu erzeugen
• dieser Branch kann sehr langlebig sein, muss aber letztendlich wieder in den master überführt werden

2. Developer Branch

develop

• Entwickler Haupt-Branch / Trunk
• Basis für feature Branches
• dauerhafter Branch

3. Feature Branches

feature/xy_Description

• Arbeits-Branch für den Entwickler
• wird aus develop erstellt und auch wieder in den develop zurück gemerged (Merge-Request stellen!)
• sollte nach der Zusammenführung gelöscht werden: kurzlebig
• Basis für die Benennung ist
• feature/ - fester Präfix
• xy - Nummer in Übereinstimmung mit der Gitlab Ticketnummer
• _Description - freie Benennung
• Beispiel: feature/35_ALMClient
• feature Branches sind regelmäßg vom develop zu aktualisieren
• feature Branches sind vom master Branch zu aktualisieren nach Erstellung eines neuen Releases oder eines Hotfixes.
• wurde ein Branch erstellt, wird automatisch ein Jenkins Build gestartet
• Cherry Picking ist erlaubt.
• Merge
• Merge Request starten
• Codereviews durchführen

Problematik

• Feature branches sollen Themenbezogen sein und können mehrere Untertickets haben.
• Das Hauptticket z.B. mit der Nummer 42 ist auch der Namensgeber des Branches

feature/42_pop1

• kleinere Bugfixes und LanguageTagger sollten nicht den aufwändigen MergeRequest und CodeReview Prozess durchlaufen müssen
• im Gegensatz muss aber gewährleistet werden Codierungs Standards einzuhalten

Festlegung

• Entwickler dürfen direkt in den Branch develop pushen, wenn
• es zur Aufgabe 1 Gitlab Issue gibt
• diese Aufgabe innerhalb des Tages abgearbeitet ist
• vom Entwickler die Styleguides eingehalten werden (Selbstkontrolle)
• Ebenso dürfen Sprachtags nur in den develop Branch gepusht werden!
• Es gibt keinen MergeRequest
• CodeReviews dürfen immer durchgeführt werden, sind aber hier nicht bindend
• Es ist mit einer Entwicklerversion durch den Applikateur oder einen Kollegen zu testen
• alle anderen Issues sind in einem eigenen Branch zu realisieren

4. Nicht erlaubte Zeichen

• in Branchnamen dürfen keine Sonderzeichen stehen!
• deutsche Umlaute ä ö ü sowie das ß sind auch nicht erlaubt
• Jenkins kann sonst kein Build erstellen
• keine Bindestriche -

nicht erlaubt:
feature/4_Süßwaren
feature/4_Sueßwaren
feature/4_Süsswaren

erlaubt:
feature/4_Suesswaren

5. Cherry-Pick

• Cherry Picking wird für die Erstellung Releases nicht unterstützt! Es wird immer der letzte Stand des develop Zweigen verwendet.
• Cherry Picking von develop zu Branch oder Branch zu Branch ist erlaubt