senäh

17senäh und so…

Versionskontrolle

Allgemein
07. Mai 2012
Kommentare: 2

Gedanken zu Versionskontrolle (Subversion, Git & Co)

Kategorien: Allgemein | 07. Mai 2012 | Kommentare: 2

Ein netter Arbeitskollege hat mir mal ein Buch ausgeliehen: Der pragmatische Programmierer*. Während meines Silvesterurlaubs in Dänemark bin ich auch mal dazu gekommen in dem Werk zu lesen. Abgesehen von der in diesem Blogpost besprochenen Thematik kann ich nur jedem empfehlen es mir gleich zu tun. Das Buch beinhaltet eine Sammlung generischer Vorgehensweisen, die ein Software-Entwickler anstreben sollte. Damit man bei all den klugen Ratschlägen den Überblick behält, werden regelmäßig wichtige Regeln herausgehoben. Eine dieser Regeln lautet: du sollst Versionskontrolle verwenden.

Ich hatte heute ein Schlüsselerlebnis und möchte euch deshalb meine Meinung zu diesem Thema nicht vorenthalten. Dabei werde ich für alle, die mit dem Begriff Versionkontrolle (=VK) nichts anfangen können, erst einmal klären, was genau ich damit meine. Danach werde ich einige offensichtliche Vorteile benennen und abschließend noch ein paar positive Aspekte einstreuen, die vielleicht erst nach einem ersten Blick bewusst werden.

Was bedeutet Versionskontrolle?

Wie man mit ein wenig Holmes’schen Gespür erahnen kann, ist mit VK das regelmäßige Speichern eines Zwischenstandes gemeint. Wer also Software entwickelt, kann im einfachsten Fall alle offiziellen Releases für den späteren Zugriff irgendwo hinterlegen.

Eigentlich geht das Ganze aber noch ein paar Schritte weiter. Man kann nicht nur offizielle Releases zwischenspeichern, sondern auch die Implementierung einzelner Features. Von da aus kann man weitergehen und einzelne Schritte auf dem Weg zur Feature-Implementierung sichern.

In jedem Fall hat man am Ende viele verschiedene Versionen seiner Software vorliegen, auf die man bei Bedarf zurückgreifen kann. Apropos Bedarf: worin besteht dieser eigentlich?

Eine kurze Geschichte

Da ich es hin und wieder auf Twitter rumposaune, könnte der ein oder andere mitbekommen haben, dass ich zur Zeit an meiner Bachelorarbeit schreibe. Da Festplatten immer dann den Löffel abgeben, wenn man es am wenigsten gebrauchen kann, wende ich neben meinem wöchentlichen Backup und dem Speichern in der Cloud noch eine dritte Havarieverhinderungsmaßnahme an: das tägliche Sichern per SVN (eine mögliche Form der VK).

Mir kam das in der Vergangenheit bereits beim Entwickeln für Studienprojekte zu Gute. Zwar handelte es sich dabei stets um PHP-Applikationen – also um Dateien wesentlich anderer Natur – jedoch erschien mir die Idee recht clever. Zurecht.

Ich untersuche in meiner Arbeit ein Protokoll, welches auf SOAP basiert. Motiviert wie ich war habe ich mir einiges zu SOAP durchgelesen und das ganze dann wissenschaftlich korrekt niedergeschrieben. Kurz darauf habe ich festgestellt, dass SOAP zwischenzeitlich ein Update erfahren hat. Ich war etwas genervt, aber noch motiviert genug um einen Tag in der Bibliothek zu verbringen und dort SOAP 1.2 und seine Änderungen in meine Niederschrift einfließen zu lassen.

Jetzt mache ich mich an die Untersuchung des eigentlichen Protokolls und stelle fest: es setzt noch auf SOAP 1.1, den eigentlich veralteten Standard. Meine Überarbeitung war also für’n Hintern. Als wäre da nicht genug hatte ich natürlich alle Textpassagen, die dank SOAP 1.2 irrelevant wurden, gelöscht.

Jeder nicht so geekige Bachelorant hätte ein Problem gehabt. Da ich aber wie bereits erwähnt jeden Abend den aktuellen Stand per SVN verewige, musste ich nur schauen, wie mein Schriebsel denn vor meinen Änderungen ausgesehen hatte, und diesen Teil wiederherstellen. BAZINGA!

Die offensichtlichen Vorteile

Und damit wären wir auch bei den Vorteilen von VK angelangt. In diesem Fall: ein Backup. Das geht aber mit anderen Tools auch, oftmals sogar effizienter. Der Hauptgrund für eine VK liegt eher beim Tracken der Änderungen und – wie in meinem Falle geschehen – der schnellen Wiederherstellung alter Stände.

Unglaublich mächtig und eigentlich unerlässlich werden Tools wie SVN, Git & Co. im Hinblick auf Teamwork. Mehrere Entwickler, die an einem Projekt arbeiten, brauchen eine Methodik, um Dateien ändern zu können, ohne die Änderungen eines anderen Entwicklers zu überschreiben. Hier spielt VK all seine Stärken aus.

Jeder Entwickler zieht sich eine lokale Kopie, die er verhunzen kann, wie er lustig ist. Ist er einmal der Meinung, dass sein Code einen Stand erreicht hat, der dem Rest des Teams zumutbar ist, sagt er “liebe VK, übernimm doch mal bitte meine Änderungen”. Bei SVN nennt sich das Ganze commit. Dabei wird dermaßen clever agiert, dass eure Änderungen z.B. an einer CSS-Datei nicht die Änderungen der restlichen Entwickler überschreiben. Die Software hinter der verwendeten VK sucht sich die Stelle, an die euer Code-Block gehört, platziert ihn dort und alle sind glücklich.

Im Fall der Fälle kann man außerdem bestimmen, wer für Zeile 666 verantwortlich ist, die das Layout im Opera zerhaut. Auch das umständliche “was genau hast’n da jetze geändert?” fällt weg, da man verschiedene Versionen derselben Datei miteinander vergleichen und Unterschiede dabei kenntlich machen kann.

Review-Charakter

Auch wenn es unkonventionell klingt: VK hilft außerdem dabei täglich zu prüfen, was man am jeweiligen Tag geschafft hat. Wenn ihr mit dem GTD-Prinzip vertraut sein solltet, erinnert euch das eventuell an die dabei notwenigen täglichen Rückblicke.

Da jeder Commit von einer Nachricht beschrieben werden sollte, ist man gezwungen sich Gedanken darüber zu machen, was genau man eigentlich heute gemacht hat. Das wiederum lässt sich mit dem vergleichen, was man sich ursprünglich vorgenommen hat und hilft somit sich einschätzen zu lernen.

Geleistetes nicht wegwerfen

Das Beispiel oben soll einerseits zeigen, dass VK generell auch für Projekte sinnvoll ist, bei denen man mitunter gar nicht an den Einsatz denken würde. Andererseits wollte ich euch zeigen, dass man nie wissen kann, was man noch an scheinbar überholten Texten, Code-Blocks & Co brauchen kann.

Ich bin auf einen aktualisierten Standard gestoßen und wäre nie auf die Idee gekommen, das ein Protokoll, das verhältnismäßig jung ist, auf die ältere Version des Standards setzt. Ein meiner Meinung nach nicht allzu abwegiger Gedanke, oder? Deshalb Bottomline: werft Geschaffenes nicht einfach weg, archiviert es mit VK.

Wann sollte ich Versionkontrolle verwenden?

Ganz kurz: immer. Auch – oder sollte ich vor allem sagen? – wenn es sich um ein 1-Mann-Projekt handelt. Ein lokales Repository ist schnell eingerichtet. Es gibt keine Ausrede, die den Verzicht begründet. Darum bin ich auch der erste, der – sobald sich die Möglichkeit auftut – ganz laut Ich hab’s euch ja gesagt schreien wird 😉


* Es handelt sich hierbei um einen sogenannten Affiliate-Link. Wenn euch das Buch interessiert und ihr es über diesen Link kauft, bekommt dieser Blog einen Teil des Erlöses gutgeschrieben. Wir würden uns freuen 😉

Autor: Enno

Ich bin Enno. PHP ist mein Ding, aber auch alles Neue rund um die Themen HTML5, CSS3 & Co finde ich interessant. Ich mag es Leuten zu helfen und mein Wissen weiterzugeben. Sollte dir mein Beitrag gefallen haben, lass doch nen Kommentar da oder benutze einen der Social Buttons, um deinen Dank auszudrücken ;)