Den heutigen Beitrag möchte ich mit einer nicht ganz ernst gemeinten, aber von der Wahrheit nicht weit entfernten Geschichte beginnen:
Mit Stolz haben wir die Version 1.0 der bahnbrechenden neuen Küchendienstverwaltungssoftware live geschaltet und schon wird fleißig an all den tollen neuen Features für 1.1 gewerkelt. Auch auf das Nachfüllen der Keksdose soll nun automatisch alle 2 Tage hingewiesen werden. Doch nur kurz hält die Euphorie an. Schon kommt der Chef durch die Bürotür gestürmt: Warum muss ich nächsten Freitag den Müll rausbringen? Da kann nur ein Fehler vorliegen. Kümmert euch darum!
Also muss alles stehen und liegengelassen werden, damit der vermeintlich "Bug" in Version 1.1 ausgebügelt werden kann. Wer jetzt noch mit SVN (oder gar CVS) arbeitet, dem wird der folgende Ablauf bekannt vorkommen:
- 1.0 in ein neues Verzeichnis auschecken
- die Änderungen vornehmen und einen neuen Branch erstellen
- die Änderungen in den aktuellen Entwicklungsbranch importieren
Mit strenger Disziplin ist dieses Vorgehen sicherlich auch gut umzusetzen, aber hier möchte ich jetzt git-flow vorstellen. git-flow ist eine Erweiterung von git, die die Arbeit mit einzelnen Versionen eines Projekts wesentlich vereinfacht. Das ganze will ich hier anhand eines kleinen Beispiels verdeutlichen. Zunächst müsst Ihr natürlich git installieren (unter Ubuntu beispielsweise mittels apt-get install git-core). Nun muss noch git-flow nachgerüstet werden (unter Ubuntu gibt hierzu das Package git-flow). Die Installationsanleitung für alle anderen Betriebssysteme findet Ihr hier.
Nun legen wir unser kleines Testprojekt an und initialisieren auch gleich git-flow:
git init git flow init
git-flow wird Euch nun einige Fragen stellen, wie beispielsweise die einzelnen Branches heißen sollen. Hier könnt Ihr getrost alles bei den Standardwerten lassen. Nun erstellen wir unser erstes Commit.
echo "Der Beginn eines epischen Projektes." > readme.txt git add readme.txt git commit -a -m "readme.txt hinzugefügt"
Als nächstes bauen wir aus den bestehenden Änderungen den ersten Release fertig machen
git flow release start 1.0 git flow release finish 1.0
git-flow wird nun noch nach den Änderungen für Version 1.0 fragen. Füllt diese aus und werdet zeuge der Magie:
Switched to branch 'master' Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+) create mode 100644 readme.txt Deleted branch release/1.0 (was 26ce65e). Summary of actions: - Latest objects have been fetched from 'origin' - Release branch has been merged into 'master' - The release was tagged '1.0' - Release branch has been back-merged into 'develop' - Release branch 'release/1.0' has been deleted
Automatisch werden die Änderungen in den Branch "master" eingebaut, der Release getaggt und Änderungen die Ihr während git flow release start und finish eingepflegt habt werden in Euren "develop"-Branch geschrieben.
Wollt Ihr nach einigen weiteren Releases einen Fehler ausbessern, könnt Ihr den Befehl git flow hotfix nutzen. Dieser erlaubt es einen bestehenden Release auszuchecken und Änderungen vorzunehmen.
git flow hotfix start 1.0.1 1.0
Nun nehmt Ihr Eure Änderungen vor, checkt alles mittels git commit ein und schließt den Hotfix ab:
git flow hotfix finish 1.0.1
Nun kann wie gewohnt weitergearbeitet werden. Nach einem weiteren Release könnte eure Commit-History beispielsweise so aussehen:
Wer mehr wissen will sollte sich unbedingt den folgenden Blogeintrag des Authors von git-flow ansehen.
Somit bleibt mir nur noch die abschließende Frage "Why aren't you using git-flow"?