1 Jahr Git - Ein Rückblick

Blog Rückblick 1 Jahr Git von Daniel Rotter
Blog Rückblick 1 Jahr Git von Daniel Rotter

Vor etwas mehr als einem Jahr haben wir unser Versionsverwaltungssystem gewechselt. Statt SVN verwenden wir nun Git, das, sicher nicht zuletzt wegen der steigenden Popularität von Github, sehr oft für OpenSource-Projekte verwendet wird.

Da ich mich in letzter Zeit mit dem Thema Versionskontrolle mit Git beschäftigen durfte, möchte ich jetzt die möglichen Beweggründe für einen Wechsel zu Git sowie die Unterschiede zu SVN erläutern.

Was ist ein Versionskontrollsystem?

Aus der professionellen Sofwareentwicklung sind Versionskontrollsysteme kaum mehr weg zu denken. Dabei handelt es sich um Systeme die sich Snapshots von den verschiedenen Entwicklungsstufen eines Softwareprojekts halten. Man kann sich das also wie eine sehr große Undo-History vorstellen. Eine weitere nützliche Funktion von Versionskontrollsystemen ist die Möglichkeit verschiedene Entwicklungsstände zusammenzuführen, was im Fachjargon als "mergen" bezeichnet wird.

Natürlich gibt es eine Unmenge von verschiedenen Systemen dieser Art. Eine ganz grobe Einteilung ist die Unterscheidung zwischen zentralen und dezentralen Versionskontrollsystemen. SVN verfolgt diesen zentralen Ansatz. Das bedeutet, dass das Repository (also das Softwareprojekt) auf einem Server liegt und der Entwickler eine Verbindung braucht, um wirklich effektiv entwickeln zu können.

Im Gegensatz dazu ist Git ein dezentrales oder auch verteiltes System. Das bedeutet, dass sich jeder Entwickler eine gesamte Kopie des Repository klont und somit alle Informationen und die gesamte History auch lokal verfügbar hat. Dieses Vorgehen hat einige Vorteile, auf die ich noch näher eingehen werde.

Trotz dieses dezentralen Ansatzes braucht es auch eine wirklich aktuelle Version des Projekts. Genau dieses Anliegen versuchen verschiedene Code Hosting Seiten zu befriedigen. Unser Code liegt auf Github. Eine weitere bekannte Alternative, die ebenfalls Git verwendet, ist Bitbucket.

Vom Verzweigen und Zusammenführen

Die meisten Versionskontrollsysteme ermöglichen es verschiedene Entwicklungsstände eines Projekts in mehreren Zweigen bzw. Branches zu verwalten. Wenn man der Meinung ist, dass ein Branch fertig gestellt ist, kann man den Branch wieder mit einem anderen zusammenführen, oder, falls man mit dem Ergebnis nicht zufrieden ist, diesen Branch auch einfach verwerfen. Die getätigte Arbeit geht dann verloren, man hat aber danach wenigstens wieder einen funktionierenden und sauberen Stand.

Bei SVN sind die für das Branching notwendigen Operationen sehr umständlich, weil das System sehr viel mit dem entfernten Server kommunizieren muss. Das ist wahrscheinlich auch der Grund dafür, dass man mit dem Erstellen von neuen Zweigen bei SVN eher vorsichtig ist, da das Zusammenführen danach, wieder nicht besonders einfach ist.

Bei Git wird von diesem Feature sehr oft Gebrauch gemacht, deswegen hat man auch sehr auf die Performance dieser Operationen geachtet. Neben der wegfallenden Netzwerkkommunikation, da alle notwendigen Daten ja lokal vorhanden sind, ist auch die Verwaltung der verschiedenen Entwicklungsstände auf einen Prozess mit vielen Verzweigungen und Zusammenführungen optimiert. Durch diese Entscheidungen bei der Konzeption von Git wird der Entwicklungsprozess maßgeblich beeinflusst. So wird die Kollaboration mit anderen Entwicklern sehr vereinfacht. Jedem ist es freigestellt eine eigene Kopie (Fork) des Projekts zu erstellen, und daran zu arbeiten. Dann können die Änderungen mittels Email, oder auf Github auch mit einem sogenannten Pull-Request, in das Originalprojekt zurück fließen. Das bedeutet also dass man sich sehr einfach an OpenSource-Software beteiligen kann, ohne ein Mitlglied des Kernteams zu sein. Meiner Meinung nach werden dadurch große OpenSource-Projekte, wie der Linux-Kernel (für den Git übrigens entwickelt wurde), erst ermöglicht.

Praxisbeispiel ZOOLU

Das Repository unserer CMS-Lösung ZOOLU liegt auch auf Github. Anhand diesem Projekt möchte ich im folgenden einige Vorteile bei der Arbeit mit Git aufzählen.

Zuerst ist es natürlich wichtig, sich ein Konzept für den Entwicklungsprozess zu überlegen. Der Prozess für ZOOLU ist im Github-Wiki beschrieben. Es ist wirklich zu empfehlen, sehr oft Branches zu verwenden - auch wenn ein Prozess ähnlich wie bei SVN möglich ist (das hat uns den Umstieg doch sehr erleichtert).

Wir haben uns dazu entschieden zwei ständige Branches zu haben: einen master-Branch, der die letzte stabile Version darstellt und einen develop, der die aktuellsten fertig gestellten Features und Bugfixes beinhaltet.

Vom develop-Branch aus werden neue Branches erstellt, in denen neue Features oder Bugfixes entwickelt werden. Nachdem jemand die Entwicklung in so einem flüchtigen Branch (alle Branches außer master und develop werden nach dem Mergen wieder gelöscht) erstellt hat, kann dieser einen Pull Request auf Github stellen. Dann werden die Entwickler, die die notwendigen Rechte auf diesem Github-Projekt haben, informiert und können die geplanten Änderungen integrieren, insofern sie die notwendige Qualität besitzen. Andernfalls kann man den Ersteller des Pull Requests dazu auffordern gewisse Verbesserungen vorzunehmen oder sich dazu entscheiden, die Änderungen überhaupt nicht zu übernehmen.

Sobald der develop-Branch unsere gewünschten Änderungen beinhaltet, kann man einen Release-Prozess starten. Auch hierfür wird ein eigener Branch angelegt, bei dem sich ein wirklich sichtbarer Vorteil ergibt: Man kann in diesem Release-Branch nur mehr Bugfixes aufnehmen und die Entwicklung kann trotzdem im develop-Branch fortgeführt werden. Das bedeutet, dass wir im Prinzip einen Feature-Freeze vollziehen können. Neue Features, die erst nach diesem Zeitpunkt eingeliefert werden, müssen auf ihre Veröffentlichung bis zum nächsten Release warten.

Nachdem das Release zur Genüge getestet geworden ist, kann man diese Änderungen in den master-Branch übernehmen und das Release mit einem sogenannten Tag markieren. Man darf natürlich auch nicht vergessen, diese Änderungen in den develop-Branch zurückzuführen.

Fazit

Zusammengefasst möchte ich behaupten, dass wir mit dem Wechsel von SVN zu Git und unserem neuen Entwicklungsprozess, das Potenzial geschaffen haben, um unsere Codequalität zu erhöhen. Das immer wieder neue Erstellen von Branches ist leider tatsächlich etwas mehr Aufwand, allerdings erleichtert dieses Vorgehen in Kombination mit den Pull-Requests von Github das Durchführen von Code Reviews.

Die Einstiegshürde habe ich auch nicht als besonders hoch empfunden, da man Git auch ähnlich wie SVN verwenden kann. Man wird nach einiger Zeit aber merken, dass man damit nicht das volle Potenzial dieses Systems ausschöpft.

Zum Schluss möchte ich auch noch jeden interessierten Entwickler dazu einladen einen Fork von ZOOLU zu erstellen, um unseren neuen Entwicklungsprozess selbst erleben zu können.

Diskutieren Sie mit uns auf Facebook und Twitter . Natürlich freuen wir uns auch über ein E-Mail von Ihnen.

Mehr Artikel zum Thema:

loading
Nach oben