Git Dateien verschiedener Versionsstände
Zur Abbildung eines speziellen Freigabeprozesses von Dokumentvorlagen und Textbausteinen entstand der Wunsch, manuell zu selektieren, welche Dateien von einer Entwicklungsstage in die nächste transportiert werden.
Als System zur Versionskontrolle sollte das bisher genutzte Subversion (SVN) durch git abgelöst werden.
Wir haben uns dazu zwei Varianten im Kontext des git Versionskontrollsystems überlegt und stellen diese im folgenden vor.
Im Fazit wird schließlich betrachtet, wie eine gänzlich alternative Herangehensweise aussehen könnte.
Als Fallbeispiel sollen Sternchentexte von Kommunikationsverträgen dienen.
Im hypothetischen Beispiel gibt es einen Basisvertrag, mit bestehenden Vertragsbedienungen, Klauseln und Sternchentexten (das Kleingedruckte) für das Marketing.
Daraus ergeben sich die folgenden Dateien
-
Vertragstexte:
vertraege.txt -
Kündigungsbedingungen:
laufzeiten.txt -
Sternchentexte:
sternchen.txt
Zum Stand 1.1.2025 gibt es lediglich den Basisvertrag, der jederzeit gekündigt werden kann und 20 Euro im Monat kostet.
Am 1.3. wird ein neuer Vertragstyp Europlusbonus eingeführt, bei dem Kunden, die mit den Airlines Ciyhansa oder Eurodiscover fliegen von kostenlosem Wifi an Bord profitieren.
Allerdings kommt damit eine Mindestvertragslaufzeit von sechs Monaten dazu.
Also: Basisvertrag muss angepasst werden um die Mindestvertragslaufzeit und die Benefits anzugeben.
Aber auch neue Sternchentexte kommen hinzu, denn gratis Wifi gibt es natürlich nur in alten Flugzeugen des Typs A319 und A320.
Zum 1.6. wird der Vertrag erneut erweitert.
Vielflieger mit dem Status Eiserner-Gartenstuhl bekommen nun einen Rabatt von einem Euro, solange sie mindestens einen Flug im Quartal mit der Airline durchführen.
Das gilt aber nur, wenn es kein Codeshareflug ist, bei dem die ausführende Airline nicht Cityhansa, Eurodiscover oder Deutsche Bahn ist.
Neben den offensichtlichen Anpassungen gibt es hier Abhängigkeiten zu berücksichtigen, denn die neuen Sternchentexte dürfen auch bei einer Verschiebung der Einführung des Europlusbonus-Tarifs auf einen späteren Zeitpunkt nicht zur Publikation verwendeten werden.
Werfen wir einen Blick auf verschiedene Umsetzungsoptionen mit git.
Als grundsätzliches Vorgehen zum Staging zwischen verschiedenen Umgebungen sollen zwei Verfahren kombiniert werden:
-
Entwicklung und Integration auf dem "stage" Branch zur fachlichen Abnahme
-
Überführung auf den "prod" Branch als technische Absicherung gegen direkte, händische Änderungen
-
Erstellung eines Tags vom "prod" Branch als manuelles Quality-Gate und zur Nachvollziehbarkeit von Freigaben
Das Design von git hat dabei eine oft unbeachtete Eigenschaft:
Eigentlich kennt git lediglich Sequenzen von inhaltlichen Änderungen und verwaltet die Abbildung auf Dateien separat.
Das hat in git beispielsweise den Vorteil, dass Änderungen von Dateinamen und auch der Position einer Datei in der Ordnerstruktur separat vom Inhalt bei der Zusammenführung paralleler Bearbeitungen betrachtet werden kann.
Dadurch reduzieren sich Konflikte.
Das macht es jedoch bei git im Vergleich zu Subversion schwieriger, den Anwendungsfall abzubilden, dass eine Teilmenge von Dateien konsistent bezüglich eines Versionsstandes in eine anderen Branch überführt werden soll.
Stellen wir zunächst den Basisstand in git her, bei dem der Basisvertrag durch das Tag "2025-01-01-basis" in Produktion bereitgestellt wird.
$ mkdir /tmp/demo; cd /tmp/demo
$ git init
$ git checkout -b stage
$ echo "Basisvertrag: 20 Euro/Monat" > vertraege.txt
$ echo "Basisvertrag: Keine Mindestlaufzeit, monatlich kündbar" > laufzeiten.txt
$ echo "" > sternchen.txt
$ git add .
$ git commit -m "Basisvertrag, 1.1.2025"
$ git checkout -b prod
$ git tag "release/2025-01-01-basis"
$ git checkout stageNun gilt es zunächst den neuen Vertragstyp in git bereitzustellen und anschließend die Erweiterung für Vielflieger. Von der anzuwendenden Strategie hängt jedoch ab, wie das Vorgehen bei der initialen Erstellung der Änderungen vorzugehen ist.
Feature Branches mit Subbranches
Eine Variante ist die Verwendungen von Branches. Dabei werden in git die jeweiligen Zwischenstände als Branches ausgeführt. Diese können dann durch einen Merge produktiv genommen werden.
Wichtig bei diesem Vorgehen ist, dass aufeinander aufbauende Zwischenstände separat als git commit und Branch abgebildet werden. Dadurch ist gewährleistet, dass diese Zwischenstände jeweils als einzelne Stufen produktiv genommen werden können.
$ cd /tmp
$ cp -a demo demo-branch
$ cd demo-branch
$ git checkout -b eurobonus-2025-03-01
$ echo "Eurobonusplusvertrag: 20 Euro/Monat, kostenloses Wifi auf Flügen mit Ciyhansa oder Eurodiscover" >> vertraege.txt
$ echo "Eurobonusplusvertrag: Mindestlaufzeit 6 Monate" >> laufzeiten.txt
$ echo "Stern-Eurobonusplusvertrag: Wifi gibt es nur in Flugzeugen des Typs A319 und A320" >> sternchen.txt
$ git add .
$ git commit -m "Eurobonus 1.3.2025"
$ git checkout -b gartenstuhl-2025-06-01
$ echo "2-Stern-Eurobonusplusvertrag: Vielflieger mit dem Status Eiserner-Gartenstuhl einen Rabatt von einem Euro bekommen, solange sie mindestens einen Flug im Quartal mit der Airline durchführen." >> sternchen.txt
$ echo "3-Stern-Eurobonusplusvertrag: Der Rabatt wird nur gewährt, wenn mindestens ein Flug im Quartal kein Codeshareflug ist, bei dem die ausführende Airline nicht Cityhansa, Eurodiscover oder Deutsche Bahn ist." >> sternchen.txt
$ git add .
$ git commit -m "Eurobonus-Gartenstuhl-Rabatt 1.6.2025"
// Abnahme fuer den ersten Teil kann nun erfolgen
$ git checkout stage
$ git merge eurobonus-2025-03-01
$ git checkout prod
$ git merge stage
$ git tag "release/2025-03-01-eurobonus"
// Abnahme fuer den zweiten Teil kann nun erfolgen
$ git checkout stage
$ git merge gartenstuhl-2025-06-01
$ git checkout prod
$ git merge stage
$ git tag "release/2025-06-01-garstenstuhl"Dies Vorgehen illustriert einige wichtige Aspekte in der Anwendung von git, um die fachlichen Anforderungen umzusetzen: Zum einen ist es empfehlenswert sowohl bei den Branches, Tags als auch Commits auf sprechende Bezeichnungen zu achten.
Zudem ist es wichtig aufeinander aufbauende Branches zu verwenden, um das Mergen späterer Stände einfach und konsistent zu gestalten, auch wenn es noch nachträgliche Änderungen an den Vorversionen gab.
Feature Branches und cherry-picking
Ein alternativer Ansatz verwendet weniger Branches und die Commits werden dabei herausgepickt und auf einen Integrationsbranch - hier "stage" - übernommen.
$ cd /tmp
$ cp -a demo demo-picking
$ cd demo-picking
$ git checkout -b develop
$ echo "Eurobonusplusvertrag: 20 Euro/Monat, kostenloses Wifi auf Flügen mit Ciyhansa oder Eurodiscover" >> vertraege.txt
$ echo "Eurobonusplusvertrag: Mindestlaufzeit 6 Monate" >> laufzeiten.txt
$ echo "Stern-Eurobonusplusvertrag: Wifi gibt es nur in Flugzeugen des Typs A319 und A320" >> sternchen.txt
$ git add .
$ git commit -m "Eurobonus 1.3.2025"
#commit hash wird später verwendet
$ echo "2-Stern-Eurobonusplusvertrag: Vielflieger mit dem Status Eiserner-Gartenstuhl einen Rabatt von einem Euro bekommen, solange sie mindestens einen Flug im Quartal mit der Airline durchführen." >> sternchen.txt
$ echo "3-Stern-Eurobonusplusvertrag: Der Rabatt wird nur gewährt, wenn mindestens ein Flug im Quartal kein Codeshareflug ist, bei dem die ausführende Airline nicht Cityhansa, Eurodiscover oder Deutsche Bahn ist." >> sternchen.txt
$ git add .
$ git commit -m "Eurobonus-Gartenstuhl-Rabatt 1.6.2025"
#commit hash wird später verwendet
// Abnahme fuer den ersten Teil kann nun erfolgen
$ git checkout stage
$ git cherry-pick #hash-version-1
$ git checkout prod
$ git merge stage --squash
$ git tag "release/2025-03-01-eurobonus"
// Abnahme fuer den zweiten Teil kann nun erfolgen
$ git checkout stage
$ git cherry-pick #hash-version-2
$ git checkout prod
$ git merge stage --squash
$ git tag "release/2025-06-01-garstenstuhl"Bei diesem Verfahren werden einzelne Commits von einem Branch auf einen anderen transplantiert. Hier es noch wichtiger, bei den Commits sauber zu arbeiten, sonst wird das cherry-picking sehr aufwändig und noch fehleranfälliger, als es eh schon ist.
Manueller Checkout
Eine weitere Option, eine Abwandlung aus dem ersten Ansatz:
Es wird wieder mit Feature-Branches gearbeitet, dabei jedoch manuell ausgewählt, welche Datei welchen exakten Stand beinhalten soll.
Git ermöglicht dies durch das checkout Kommando, bei dem pro Datei ein exakter Stand im git referenziert werden kann.
Diese Zusammenstellung kann anschließend als neuer Commit gespeichert werden.
$ cd /tmp
$ cp -a demo demo-branch
$ cd demo-branch
$ git checkout -b eurobonus-2025-03-01
$ echo "Eurobonusplusvertrag: 20 Euro/Monat, kostenloses Wifi auf Flügen mit Ciyhansa oder Eurodiscover" >> vertraege.txt
$ echo "Eurobonusplusvertrag: Mindestlaufzeit 6 Monate" >> laufzeiten.txt
$ echo "Stern-Eurobonusplusvertrag: Wifi gibt es nur in Flugzeugen des Typs A319 und A320" >> sternchen.txt
$ git add .
$ git commit -m "Eurobonus 1.3.2025"
$ git checkout -b gartenstuhl-2025-06-01
$ echo "2-Stern-Eurobonusplusvertrag: Vielflieger mit dem Status Eiserner-Gartenstuhl einen Rabatt von einem Euro bekommen, solange sie mindestens einen Flug im Quartal mit der Airline durchführen." >> sternchen.txt
$ echo "3-Stern-Eurobonusplusvertrag: Der Rabatt wird nur gewährt, wenn mindestens ein Flug im Quartal kein Codeshareflug ist, bei dem die ausführende Airline nicht Cityhansa, Eurodiscover oder Deutsche Bahn ist." >> sternchen.txt
$ git add .
$ git commit -m "Eurobonus-Gartenstuhl-Rabatt 1.6.2025"
// Abnahme fuer den ersten Teil kann nun erfolgen
$ git checkout stage
$ git branch -v
$ git checkout vertraege.txt #hash-version-1
$ git checkout laufzeiten.txt #hash-version-1
$ git checkout sternchen.txt #hash-version-1
$ git add .
$ git commit -m "Integration Eurobonus 1.3.2025"
$ git checkout prod
$ git merge stage
$ git tag "release/2025-03-01-eurobonus"
// Abnahme fuer den zweiten Teil kann nun erfolgen
$ git checkout stage
$ git branch -v
$ git checkout sternchen.txt #hash-version-2
$ git add .
$ git commit -m "Integration Gart6nstuhl 1.3.2025"
$ git checkout prod
$ git merge stage
$ git tag "release/2025-06-01-garstenstuhl"Bei diesem Verfahren liegt die Komplexität darin, dass für jede Datei durch einen gesonderten Mechanismus nachgehalten werden muss, welche Version anzuwenden ist. Dies kann durch etablierte Fachverfahren bereits gegeben sein und dies auf den ersten Blick sehr aufwendige Verfahren sogar gewünscht sein. Die Möglichkeiten und Vorteile der git Versionsverwaltung kommen dabei jedoch lediglich in Grundzügen zum Einsatz.
Fazit
Die Umsetzung mit git orientiert sich sehr stark an den Vorgaben und Wünschen der Anforderungssteller. Diese lassen sich in der Tat mit git durch verschiedene Prozesse abbilden, die die diskutierten Eigenschaften und Konsequenzen aufweisen.
Bei mehr Freiheit in der Modellierung der Umsetzung der gegebenen fachlichen Anforderungen zeigen sich jedoch vielversprechende Alternativen:
Git ist ein generisches Werkzeug.
Es ist damit zwar möglich, die fachlichen Anforderungen umzusetzen, jedoch ergibt sich damit auch entsprechender Lern- bzw. Schulungsaufwand bei den Nutzern und die Umsetzung mit git bringt ein nicht unerhebliches Fehlerpotential mit sich.
Als Alternative stellt sich die Abbildung in einem individuellen Softwaresystem dar.
Darin werden die jeweiligen Artefakte und Prozesse inkl. einer individuellen Oberfläche so umgesetzt, dass der Arbeitsablauf und die Anforderungen optimal unterstützt werden.
Damit ist kein git Schulungsaufwand notwendig, und die Bearbeiter finden sich in ihrer Fachlichkeit direkt wieder.
Auf der anderen Seite steht der Entwicklungs-, Betriebs und Pflegeaufwand für die Software.
Dies Vorgehen lohnt sich sicherlich, wenn eine nennenswerte Menge an zu verarbeitenden Daten zu bewältigen ist bzw. entsprechend viele Mitarbeiter involviert sind.
Eine weitere Alternative wäre ebenfalls die Verwendung eines stärker generischen Ansatzes, jedoch mit dem Fokus auf die Umsetzung von komplexeren Freigabeprozessen.
Hier drängt sich die Nutzung von Feature-Toggles als Architekturmuster mit einer entsprechenden Software zum Management von Feature-Switches auf.
Damit ließen sich nicht nur die Anforderungen in Bezug auf die vorgestellten Textbausteine, sondern sogar auf weitere Funktionalitäten in der Software selbst abbilden.
Zu den Themen git, CI/CD und Systemarchitektur bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:
Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.