Zum Inhalt

Branching Strategie

Bei der Git Branching Strategie handelt es sich um eine mögliche Methode zum Organisieren des Git Repositories. Grundlegende Informationen zu Git und eine kurze Erläuterung, was überhaupt ein Branch ist, findet man hier.

Einer Übersicht der verschiedenen Commits und Branches bekommt man durch die Verwendung der VS Code Extension Git Graph.

Release und Entwicklungsbranch

In al können durch das Arbeiten mit Apps keine einzelnen Objekte mehr in Test- oder Echtsysteme ausgeliefert werden. Es gibt nur noch die Möglichkeit komplette Apps auszutauschen. Einen Hotfix in das Kundensystem zu bringen, ohne das neue halbfertige Feature des Kollegen mit auszuliefern, kann nur noch durch das Verwenden von mindestens zwei Branches umgesetzt werden. Empfehlenswert ist pro Auslieferungssystem einen Branch zu erzeugen.

In diesem Beispiel wird ein Repository mit zwei Branches betrachtet, die wie folgt heißen:

  • Dev - Enthält den Stand der aktuellen Entwicklung
  • Release - Enthält den aktuell beim Kunden ausgelieferten Stand.

Die beiden Branches können beim Erzeugen des Repositories in Azure Dev Ops gleich mit angelegt werden.

Über ein Q/A werden die wichtigsten Fragen erklärt.

Wie sehe ich, auf welchem Branch ich aktuell arbeite?

In VS Code wird unten links der verwendete Branch angezeigt. Außerdem ist in Git Graph der ausgewählte Branch fett geschrieben. ohne|miniatur|708x708px

Wie wechsle ich den ausgewählten Branch?

Durch das Klicken auf den ausgewählten Branch unten links öffnet sich eine Auswahl mit allen vorhandenen Branches. Alternativ kann der Branch durch Rechtsklick und "Checkout Branch" gewechselt werden.

Über den Windows Explorer kann man beobachten, wie sich die Dateien durch das Wechseln des Branches verändern. ohne|miniatur|722x722px

Welche Anpassungen mache ich im Entwicklungsbranch Dev?

Eigentlich sollen alle Anpassungen im Dev Branch gemacht werden. Auf Basis dieses Branches wird entwickelt und getestet. Von diesem Branch wird nicht direkt in ein Kundensystem ausgeliefert.

Die Datenbanken der Entwickler basieren in der Regel auf diesem Branch.

Welche Anpassungen mache ich im Releasebranch?

Im Releasebranch werden Änderungen gemacht, die auch direkt ins Kundensystem ausgeliefert werden sollen. Also z.B. ein Hotfix, der dem Kunden schnell zur Verfügung gestellt werden muss. In der Produktentwicklung wird auf Basis des Releasebranches auch KatarGo Events eingebaut.

Wie bekomme ich meine Änderungen aus dem Dev Branch ins Kundensystem?

Wie oben beschrieben, wird nicht direkt vom Dev Branch ins Kundensystem ausgeliefert. Um Änderungen aus dem Dev Branch in das Kundensystem zu bekommen, müssen die Änderungen also erst in den Releasebranch. Dies erfolgt durch einen Merge.

Ein mögliches Vorgehen wäre z.B. immer am Sprintende vom Devbranch in den Releasebranch zu mergen. Technisch könnte zu jedem Zeitpunkt und beliebig oft dieser Merge durchgeführt werden.

Wie bekomme ich meinen Hotfix vom Releasebranch in den Dev Branch?

Der Hotfix, der für das Kundensystem im Releasebranch gemacht wurde, soll natürlich auch in die Entwicklungssysteme der einzelnen Entwickler. Dafür muss ein Merge von dem Releasebranch in den Entwicklungsbranch durchgeführt werden.

Was passiert beim Mergen?

Beim Mergen werden die Änderungen des einen Branch in den anderen Branch übernommen. Wichtig ist darauf zu achten, welcher Branch aktuell ausgewählt ist.

Ist der aktuell ausgewählte Branch der Entwicklungsbranch und es wird ein Merge mit dem Releasebranch durchgeführt, werden die Hotfixes aus dem Releasebranch in den Dev Branch übernommen.

Ist der aktuell ausgewählte Branch der Releasebranch und es wird ein Merge mit dem Entwicklungsbranch durchgeführt, werden die neu entwickelten Features aus dem Dev Branch in den Releasebranch übernommen.

Wie führe ich einen Merge aus?

Als erstes ist der Branch auszuwählen, der aktualisiert werden soll.

Terminal: git merge Release -> Release Branch wird in den ausgewählten Branch gemergt

Terminal: git merge Dev -> Dev Branch wird in den ausgewählten Branch gemergt

Git Graph: Commits aus Release in Dev SimpleRelease

Git Graph: Commits aus Dev in Release SimpleDev2Release

In der Git Graph Auswahl ist beim Mergen Create a new commit even if fast-forward is possible angehakt. Dieser Haken sagt aus, dass auch ein Merge Commit mit leerem Inhalt angelegt wird. Das kann die Git Historie verkomplizieren.