Als ich zum ersten Mal auf das Thema Versionsmanagement gestoßen bin, hat die ganze Welt CVS genutzt. Zu dem Zeitpunkt hatte ich es mir kurz angeschaut und mir war sofort klar, dass CVS kein geeignetes Tool für mich ist. Bereits die Tatsache, dass die Versionsgeschichte lediglich auf Basis von einzelnen Dateien getracked wurde und es somit nicht möglich war Änderungen in mehreren unterschiedlichen Dateien als atomaren Commit zu speichern war für mich ein Dealbreaker. Enttäuscht wandte ich mich wieder ab.
Einige Zeit später, als ich kurz vor dem Abitur mit mehreren Mitschülern eine umfangreiche Webanwendung entwickelt habe, wurde das Thema wieder aktuell. Ich entdeckte Subversion, ein Fork von CVS, der alle wichtigen Schwachpunkte auszumerzen schien. Und lange Zeit habe ich nichts Anderes mehr benutzt. Heute sehe ich insbesondere an der Uni, dass Subversion sich offenbar durchgesetzt hat, denn viele Studenten kennen gar nichts Anderes! Aber auch in vielen Unternehmen, wo häufig zentralisierte Strukturen vorherrschen, ist es mittlerweile zum Standard geworden. (Mit Ausnahme natürlich von solchen Unternehmen, die ausschließlich auf proprietäre Microsoft-Produkte wie – Gott bewahre! – Team Foundation Server o.ä. setzen.) In der Open Source Gemeinde hingegen hat ein anderes Tool zunehmende Beliebtheit erlangt: git.
Für mich entdeckt habe ich es vor etwa zwei Jahren, als ich für einen Kunden eine Website mit Hilfe des Symphony CMS entwickelt habe. Das Projekt hat eine kleine, aber eng zusammen arbeitende Community, die fleißig Plugins und Erweiterungen programmiert und diese auf GitHub veröffentlicht. So bin ich auf git gestoßen und neugierig wie ich bin habe ich es mir gleich genauer angeschaut – und seitdem könnte ich nicht mehr darauf verzichten!
In meinen weiteren Ausführungen setze ich voraus, dass du, werter Leser, bereits mit Versionsmanagement-Tools und insbesondere mit SVN vertraut bist. Ich werde davon ausgehend erläutern welche Vorteile git für den Workflow bietet und wie es dadurch zu einer Steigerung der Produktivität führen kann.
Zunächst ist der auffälligste Unterschied, dass git im Gegensatz zu SVN ein verteiltes Versionsverwaltungssystem ist: Es gibt keinen zentralen Server, jeder Nutzer besitzt eine vollständige Version des Repositorys. Dies führt zum einem dazu, dass die meisten Operationen ohne Internetverbindung möglich sind, zum anderen dazu, dass es immer mehrere Backups (entsprechend der Anzahl Nutzer) des Repositorys gibt – ein Ausfall des Servers ist also selbst falls dieser nicht regelmäßig gesichert wird leicht zu verschmerzen. Häufig genutzte Operationen wie Vergleiche zwischen verschiedenen Datei- und Repository-Versionen, die Erstellung von Branches sowie das lokale Speichern von Commits erfolgen sehr schnell und ohne der Notwendigkeit einer Internetverbindung.
Ein weiteres Feature von git sind lokale Commits. Diese haben sich in meiner Erfahrung als äußerst praktisch erwiesen. Bei der Entwicklung einer umfangreichen Projektkomponente will ich zwar regelmäßig meine Änderungen speichern, sodass ich bei dem Auftreten eines Bugs zu einer früheren Version zurückkehren kann. Gleichzeitig will ich meine Änderungen aber noch nicht mit anderen Team-Mitgliedern teilen, wenn sie noch nicht einen bestimmten Reifegrad erreicht haben. Dieser Workflow ist mit git Standard, Commits erfolgen zunächst lokal und müssen zur Veröffentlichung auf den Server gepushed werden. Zur besseren Dokumentation kann man die Commits vor dem Pushen mithilfe von git rebase sogar neu organisieren und mit besseren Kommentaren versehen. Dagegen tendieren SVN-Nutzer dazu, jede einzelne lokale Änderung gleich auf den zentralen Server zu commiten, sodass die History mit unnötigen Commits aufgeblasen wird und es erschwert wird sich einen Überblick über den Entwicklungsverlauf zu verschaffen. Lokale Commits sind bei SVN gänzlich unmöglich.
Das nächste große Plus von git sind die oben erwähnten Branches. In git ist es üblich, bei der Arbeit an einem neuen Feature sogenannte feature branches zu verwenden. Diese Vorgehensweise erleichtert es, alle zu der Arbeit an einem bestimmten Feature oder zu einem bestimmten Bug gehörenden Commits nachzuverfolgen. Das Erstellen einer neuen Branch ist eine simple lokale Operation: git checkout -b bug-1337. Bei SVN hingegen würde die gleiche Operation folgendermaßen aussehen: svn copy http://meinwebserver.de/svn/projekt/trunk http://url-zum-repository.de/svn/projekt/branches/bug-1337 -m "Neue Branch für Bug 1337"; svn switch ^/branches/bug-1337. Schon die Länge des Befehls lässt erahnen, warum Branches bei SVN selten benutzt werden. Zugleich sind Branches nur sinnvoll, wenn mächtige merge-Werkzeuge zu Verfügung stehen. Dies ist bei git der Fall; bei SVN hingegen ist ein Merge oft ein langwieriges und schmerzvolles Unterfangen. Warum das so ist, ist schnell erklärt: Während bei git gespeichert wird, von welcher Revision ein Branch abstammt bzw. welche Revisions eigentlich gemerged wurden, war dies bei SVN bis vor kurzem nicht der Fall. Mit SVN 1.5 wurde diese Funktionalität zwar eingeführt, aber soweit ich weiß ist das bisher nur rudimentär implementiert. So gibt es insbesondere Probleme mit Merges von umbenannten Dateien, die bei git nicht auftreten.
Ebenfalls ein Feature das ich oft verwende ist git stash: Wenn ich angefangen habe an etwas zu arbeiten und plötzlich ein wichtiger Hotfix ansteht, hilft dieser Befehl aus der Klemme: Alle Änderungen, die noch nicht committed wurden, werden vorübergehend gespeichert und die Working Copy wird auf den Stand des letzten Commits zurückgesetzt. Sobald der Hotfix fertig ist und ich wieder zu der ursprünglichen Arbeit zurückkehren will, kann ich mit git stash pop die zuvor gemachten Änderungen wieder in meine Working Copy mergen und an der Stelle weitermachen wo ich zuvor aufgehört hatte. Bei SVN hingegen ist dies nicht möglich; und weil es bei SVN auch keine lokalen Commits gibt, bleibt in diesem Fall eigentlich nur noch die Möglichkeit eines manuellen Backups der einzelnen Dateien und dem anschließenden Revert der Änderungen. Oder aber man erstellt auf dem Server eine neue Branch und committed die unfertigen Änderungen dorthin. Beides sind sehr umständliche und nicht zufrieden stellende Workflows.
Damit komme ich zum Ende dieses Beitrags. Zwar habe ich nur einen sehr kurzen Überblick über die Vorteile von git gegenüber SVN verschafft, aber ich hoffe, dass ich trotzdem das Interesse für git wecken konnte. Eine kleine Einführung findet man auf der offiziellen Website, einen umfassenderen Vergleich zwischen git und SVN gibt es hier. Und schließlich möchte ich noch folgenden Workflow empfehlen: git flow.