Versionsstrategien - Git flow

Versionierungsstrategien

Artikeldaten
Erste Version 0.1 (22.08.2012)
Aktuelle Version 0.1(22.08.2012)

1. Kurzbeschreibung

Bei der Software-Entwicklung (und auch beim Schreiben von größeren Texten) ist es sinnvoll von Zeit zu Zeit den aktuellen Entwicklungsstand zu sichern. Am Anfang reicht hierfür vielleicht die Kopie des Projektordners auf einer externen Festplatte (in z.B. einen Unterordner mit dem Zeitstempel als Namen). Irgendwann wird dies aber zu umständlich und zu unübersichtlich. Es wird Zeit über ein Versionierungssystem nachzudenken und damit auch über eine Versionierungsstrategie. Dieser Artikel soll bei dieser Entscheidung helfen. Die vorgestellten Strategien sind unabhängig von dem eingesetzten Versionierungssystem (Git, TFS, Subversion, Mercurial usw.).

2. Ein-Zweig Strategie

Versionsstrategien - Ein-Zweig

2.1. Beschreibung

Diese Strategie ist relativ einfach. Alle Änderungen werden in einen einzigen Zweig abgelegt. Sobald der Code einen Release-Status erreicht hat, wird dieser Stand ausgeliefert und mit einem sprechenden Namen (meistens Versionsnummer) versehen. Damit ist diese Release-Version jederzeit in der eigenen Versionsverwaltung schnell auffindbar. Nach der Auslieferung der Release-Version geht die Entwicklung linear weiter.

2.2. Pro

  • Sehr einfache Benutzung
  • Kein Merge zwischen unterschiedlichen Zweigen notwendig
  • Sehr gut für den Einstieg in die Versionsverwaltung geeignet
  • Sehr gut für Dokument-Versionierung (Bücher, Artikel, Manuskripte usw.)

2.3. Kontra

  • Schwer zu handhaben, wenn mehr als nu rein Entwickler beteilig ist, da während des Release-Tests keine Weiterentwicklung für nächste Version möglich ist.
  • Hotfixes einer Version sind sehr schwer zu realisieren, da eventuell bereits unvollständige Features für neue Version da sind.

3. Master-Develop Strategie

Versionsstrategien - Master-Develop

3.1. Beschreibung

Diese Strategie ist auch relativ einfach. Das eigene Versionsverwaltungssystem besteht aus zwei Zweigen. In dem Master-Zweig werden nur benannte, getestete und abgeschlossene Versionen abgelegt (z.B. Stand einer Release-Version). Der Develop-Zweig wird dagegen wie in der Ein-Strang-Strategie benutzt. Alle Projektstände, die gesichert werden sollten (egal ob der Stand vollständig und / oder lauffähig ist), werden diese in den Develop-Zweig geschrieben. Ist ein Code / Text-Stand erreicht, der an den Kunden ausgeliefert werden kann, und ist getestet, wird der Master-Zweig mit dem Develop-Zweig zusammengeführt. Danach wird der Stand des Master-Zweiges benannt (z.B. mit Versionsnummer).

3.2. Pro

  • Bietet besseren Überblick über ausgelieferte / veröffentlichte Projektstände und belässt die Flexibilität bei der täglichen Arbeit.
  • Schneller Zugriff auf benannte Stände, da diese nur im Master-Zweig vertreten sind (ohne Entwicklungsbalast).

3.3. Kontra

  • Schwer zu handhaben, wenn mehr als nur ein Entwickler beteilig ist, da während des Release-Tests keine Weiterentwicklung für nächste Version möglich ist.
  • Hotfixes einer Version sind sehr schwer zu realisieren, da eventuell bereits unvollständige Features für neue Version da sind.

4. Git-flow Strategie

Versionsstrategien - Git flow

4.1. Beschreibung

Diese Strategie ist mit Git-Versionsverwaltung entstanden, da bei Git die Zweige (branches) sehr einfach erstellt und wieder gelöscht werden könne. Hier werden zwei Arten der Zweige verwendet.

imortal branches (unsterbliche Zweige)
Das sind Zweige, die über die gesamte Dauer des Projektes bestehen bleiben. Zu solchen Zweigen gehören bei Git-Flow-Strategie master und develop Zweige
mortal branches (sterbliche Zweige)
Das sind Zweige, die nur eine begrenzte Lebensdauer haben und nach dem Erfüllen des Zwecks, gelöscht werden (können). Zu solchen Zweigen gehören bei Git-Flow-Strategie die release, hotfix und feature Zweige.

feature

Auf dem „develop„-Zweig werden direkt nur sehr kleine Änderungen gemacht. Größere Änderungen werden in eigene sterbliche Zweige ausgelagert, die mit dem Präfix „feature“ anfangen (Ursprung ist „develop„-Zweig). Die Entwicklung der neuen Funktion erfolgt dann bis zur Fertigstellung auf diesem sterblichen Zweig. In der Zwischenzeit kann man diesen „feature„-Zweig mit „develop„-Zweig abgleichen, um die Unterschiede klein zu halten, oder bestimmte bereits bereinigte Fehler auch in diesem Zweig zu korrigieren. Nach dem Beenden der neuen Funktion wird der „develop„-Zweig mit dem „feature„-Zweig zusammengeführt und der „feature„-Zweig gelöscht.

  1. Neuen Zweig mit Namen „feature/bezeichnung“ erstellen.
  2. Entwicklung auf dem neuen Zweig „feature/bezeichnung„.
  3. Develop-Zweig mit dem neuen Zweig „feature/bezeichnung“ zusammenführen, sobald die Aufgabe erledigt ist.
  4. Den neuen Zweig „feature/bezeichnung“ löschen.

release

Ist ein Stand auf dem „develop„-Zweig erreicht, der ausgeliefert werden kann, wird ein sterblicher „release„-Zweig aufgemacht (Ursprung ist „develop„-Zweig). Dieser hat den Präfix „release„. Dieser Zweig dient dem Testen des fertigen Standes, ohne die Entwicklung auf dem „develop„-Zweig zu beeinträchtigen. Wenn die Tests Fehler zum Vorschein bringen, werden diese im „release„-Zweig korrigiert, bis der Stand wirklich ausgeliefert werden kann. Dann wird dieser Stand mit „master„-Zweig zusammengeführt und ein neuer Tag auf dem „master„-Zweig erstellt. Danach wird der „develop„-Zweig mit dem „release„-Zweig zusammengeführt. Abschließend wird der sterbliche „release„-Zweig gelöscht.

  1. Neuen Zweig mit Namen „release/vVersionNummer“ erstellen.
  2. Tests und Bugfixing auf dem neuen Zweig „release/vVersionNummer“ durchführen.
  3. Nach allen Tests und Korrekturen den Master-Zweig mit dem neuen Zweig „release/vVersionNummer“ zusammenführen.
  4. Master-Zweig-Stand benennen (tagen).
  5. Develop-Zweig mit dem neuen Zweig „release/vVersionNummer“ zusammenführen.
  6. Den neuen Zweig „release/vVersionNummer“ löschen.

hotfix

Die ausgelieferten Versionen sind meistens trotzt vieler Tests nicht frei von Fehlern. In solchen Fällen wird aus dem „master„-Zweig ein neuer sterblicher „hotfix„-Zweig erstellt, um den Fehler zu korrigieren. Dieser Zweig hat das Präfix „hotfix“ und erfüllt nur eine einzige Aufgabe, den gefundenen Fehler der Version zu korrigieren. Durch den eigenen Zweig für Fehlerkorrektur wird der Entwicklungsfluss nicht beeinträchtigt. Sobald der Fehler (oder auch mehrere) korrigiert wurde, wird der „master„-Zweig mit dem „hotfix„-Zweig zusammengeführt und neu getagt (benannt). Die Fehlerkorrektur muss auch in den „develop„-Zweig. Aus diesem Grund wird auch der „develop„-Zweig mit dem „hotfix„-Zweig zusammengeführt. Abschließend wird der „hotfix„-Zweig gelöscht.

  1. Neuen Zweig mit Namen „hotfix/vVersionNummer“ erstellen.
  2. Fehlerkorrekturen auf dem neuen Zweig „hotfix/vVersionNummer“ durchführen und testen.
  3. Nach der erfolgreichen Korrektur der Fehler den Master-Zweig mit dem neuen Zweig „hotfix/vVersionNummer“ zusammenführen.
  4. Master-Zweig-Stand benennen (tagen).
  5. Develop-Zweig mit dem neuen Zweig „hotfix/vVersionNummer“ zusammenführen.
  6. Den neuen Zweig „hotfix/vVersionNummer“ löschen.

4.2. Pro

  • Arbeiten im Team ohne Beeinträchtigungen möglich, da Aufgaben in eigenen Zweigen erledigt werden.
  • Saubere Implementierung der Hotfixes für Release-Versionen ohne Beeinträchtigung der Entwicklung möglich.
  • Paralelles Weiterentwicklen der nächsten Version und vorbereiten (testen) der aktuellen durch Release-Zweige möglich.
  • Auslieferung von Hotfixes in sehr kurzer Zeit möglich, da keine Rücksicht auf den Entwicklungsstand genommen werden muss.

4.3. Kontra

  • Komplexere Handhabung als beide vorhergehenden Strategien.
  • Momentan wird nur von wenigen graphischen Tools (z.B.: SourceTree unter OS X) direkt unterstützt.
  • Erfordert Disziplin beim Entwickeln, da für jede Aufgabe ein neuer Zweig aufgemacht werden muss.
  • Nicht geeignet, wenn mehrere Release-Versionen über lange Zeiträume parallel gepflegt werden müssen.

5. Ressourcen

5.1. Bilder

5.3. Bücher

Ein Gedanke zu „Versionierungsstrategien“

Kommentar verfassen