Git Workflow

Eine kurze Erläuterung der Agentur internen Behandlung / Vorgehensweise für Projekte der Agentur77.
Die Bearbeitung und Durchführung der einzelnen Schritte, die sonst manuell über Git erfolgen, werden über Git-Flow realisiert.
Folgende Unterscheidungen bei der Initialisierung des Git-Flow sind dabei zu beachten:

Git-Flow Initialisieren

Für die Verwendung von Git-Flow muss erst eine Initialisierung in einem existierenden Git Repository erfolgen:

$ git flow init

Funktionalität (feature/)

Neues Feature

Features erweitern ein Projekt um neue Funktionalitäten. Diese werden in der Regel durch ein Lastenheft definiert und bedürfen einer vorherigen Planung.

Informationen:

• Erstellung neuer Funktionen für neue Releases
• Sichtbarkeit nur lokal. Durch Pull auf den Origin auch für andere Personen sichtbar.

Starte ein Feature

Wird immer dann gewählt, wenn eine neue Funkionsweise für ein Projekt implementiert werden soll. 

Bei der Umsetzung einer Funktionaltität wird immer ein Versionsprung erfolgen.

# z.B v1.5.2 → v1.6.0
# Erstellung eines Features via git-flow:
$ git flow feature start v1.6.0

Bei der Bearbeitung von größeren Aufgaben kann ein Feature in Sub-Features runtergebrochen werden, damit eine Umsetzung einfacher durch mehrere Personen durchgeführt werden kann.

Hier ist zu beachten, dass bei den neu erstellten Branches eine Referenz auf den Ursprungsbranch gesetzt wird.

# Erstellung eines Sub-Features via git-flow:
$ git flow feature start neues_sub_feature feature/1.6.0

Die Commits, Push und Pulls Requests werden wie gewohnt durchgeführt. 

Beende Feature

Nach Fertigstellung der Funktion wird der Branch automatisch mit folgendem Befehl gemerged und dann gelöscht.

# Fertigstellung eines Features via git-flow:
$ git flow feature finish v1.6.0  

Informationen:

• Merged v1.6.0 in develop
• Entfernt den Feature Branch
• Geht wieder in den Develop Branch

Teile Feature

Teilen eines Branches für die Bearbeitung der Aufgabe durch mehrere Personen.

$ git flow feature pull origin v1.6.0

Release (release/)

Neues Release

Wenn eine neue Version vorbereitet werden soll, um mit dem Master gemerged zu werden, erstellen wir hierzu ein Release, um die ordnungsgemäße Funktionalität des Projektes zu gewährleisten.
Bitte immer eine Release-Version erstellen, da es sonst zu Fehlern im Master kommen kann, was unbedingt vermieden werden soll.

Informationen:

• Unterstützt die Erstellung eines neuen Releases
• Ermöglicht kleinere Fehlerbehebungen und die Vorbereitung von Metadaten für eine Veröffentlichung

Starte Release

$ git flow release start v1.6.0 [BASE] 

Der Release wird immer aus dem Develop Branch erstellt.

Beende Release

Nach Prüfung des Releases wird dieses folgendermaßen fertiggestellt.

$ git flow release finish v1.6.0 

Nicht vergessen die Tags mit git push origin --tags zu pushen

Informationen:

• Merged den Release in den Master
• Kennzeichnet die Veröffentlichung mit ihrem Namen
• Merged den Release in den Develop zurück
• Entfernt den Release Branch

Teile Release

Um den Zugriff für andere Personen zu ermöglichen, wird folgender Befehl benutzt.

$ git flow release publish v1.6.0  

Hotfix (hotfix/)

Neuer Hotfix

Hotfixes werden benutzt, um schwerwiegende Fehler umgehend zu beheben. Sie sollten innerhalb einer kurzen Zeitspanne behoben werden, da es sich hierbei um Fehler handelt, die die ordnungsgemäße Funktion eines fertigen Projektes gefährden.

Informationen:

• Hotfixes entstehen aus der Notwendigkeit heraus, sofort auf einen unerwünschten Zustand einer Live-Produktionsversion zu reagieren
• Kann vom entsprechenden Tag auf dem Master-Zweig, der die Produktionsversion markiert, abgezweigt werden

Starte Hotfix

$ git flow hotfix start v1.6.1 [BASENAME]

Hotfixes haben eine eigene Versionsnummer und werden an dritter Stelle hochgezählt.

z. B. v1.6.0 → v1.6.1

Beende Hotfix

$ git flow hotfix finish v1.6.1 

Neuer Bugfix

Bugfixes werden benutzt, um bekannte Fehler zu beheben. Sie sind Teil eines Features und werden während der Fertigstellung eines Features behoben.
Es kann vorkommen, dass ein Feature nur aus Bugfixes besteht.