Ich bin kein professioneller Softwareentwickler. Dennoch schreibe ich Code. Privat zum Spaß in Python oder C, aber auch beruflich – z.B. R-Skripte zur Analyse von Daten, oder LaTeX Dokumente.

Als ich als Jugendlicher mit dem Programmieren anfing hatte ich keine Ahnung, dass es Versionskontroll-Software gibt. Später entdeckte ich SCCS und RCS und dachte: Das ist echt komplex und ich programmiere eh allein und wozu brauche ich das? Wenn ich einen Versionsstand konservieren wollte habe ich halt eine Versionsnummer vergeben und eine Kopie gemacht oder ein Zip-Archiv/tarball gebaut. Ich glaubte, das passt schon so.

Aber natürlich sind immer wieder mal kleinere Malheure passiert und ich habe dann einen ernstgemeinten Versuch mit CVS unternommen. Das gefiel mir nicht wirklich. Zwar braucht es nicht unbedingt einen Server, aber zumindest muss ich ein CVSROOT einrichten und somit liegt die Versionierungsinfo nicht beim Projekt – unpraktisch für kleine Sachen. Und so hat es eine ganze Weile gedauert, bis ich zum Versionskontrollfreak wurde.

Wozu?

Aber warum brauche ich sowas überhaupt? Was ist falsch daran, einfach immer wieder eine Kopie seiner Arbeit in ein archive Verzeichnis zu kopieren?

Ganz einfach: Es erfordert sehr viel Disziplin, das wirklich im Alltag regelmäßig zu tun. Zudem muss man dauernd von Hand die Versionsnummer hochzählen, um die Zwischenstände zu kennzeichnen und es ist schwierig, im Auge zu haben, was in welcher Version eigentlich verändert wurde. Und auch der Speicherplatz explodiert, wenn ich jedesmal eine komplette Kopie ablege. Also lieber nur die geänderten Files? Da verliert man dann binnen Minuten den Überblick. Kurz – das ist Mist.

Und wenn man mal damit angefangen hat finden sich plötzlich andauernd neue Anwendungen. Z.B. der HTML Code der eigenen Homepage, mein Blog, Meine R/LaTeX Skripte oder das VimWiki in dem ich alle meine Computer-Doku festhalte.

Außerdem fühlt es sich viel besser an, wenn man weiß, dass man ohne Probleme zu einer alten (funktionierenden) Versionen zurück kann. Z.B. wenn man eine wilde Idee ausprobieren will, oder einfach nur mal wieder den Code refaktorieren.

Auftritt: git

Seit meinem halbherzigen CVS-Versuch waren ein paar Jahre vergangen und ich hatte schon registriert, dass z.B.SVN oder Mercurial viel geschmeidiger sind, als die altbackenen Systeme. Aber so richtig motiviert war ich noch nicht.

Und dann entdeckte ich git und war sofort begeistert. Für git sprechen viele tolle Sachen: verteilte, dezentrale Versionskontrolle, super Merge Unterstützung, GitHub & Co, Geschwindigkeit, Flexibilität etc. etc.. Das klang aufregend und die Tatsache, dass ein riesen Projekt wie der LINUX Kernel damit verwaltet werden hat mich beeindruckt. Und das dezentrale Modell fand ich sehr ansprechend: Ich bastle allein auf meinem Rechner vor mich hin und zu einem gegebenen Zeitpunkt kann ich meine Arbeit in ein gemeinsames Repository schieben – das klingt gut.

Tatsächlich waren das alles tolle Features, für die ich noch garkeine echte Anwendung hatte, aber man kann ja nie wissen. Aber man muss das ja nicht gleich alles auf einmal machen. Als Einzelprogrammierer ist der Start in die Versionskontrolle mit git super einfach. Ohne Server, ohne große Infrastruktur, ohne viel Gedöns – einfach auf meinem Laptop, im jeweiligen Verzeichnis.

Ich denke, die ganzen Profi-Features sind für Neulinge zunächst eher einschüchternd. Da muss man Konzepte, wie merge, pull, clone und push verinnerlichen, deren Sinn dem Anfänger zunächst mal unklar ist. Natürlich finde ich das alles super und nutze all das nun viele Jahre intensiv, aber der entscheidende Schritt ist die Überwindung der Einstiegshürde. Nicht für Profi-Programmierer – die lernen das in Ausbildung/Studium/Praxis und es ist ganz natürlich für sie, aber für den kleinen Hobbyprogrammier, der nur mal was für den Arduino machen will, oder seine ersten Sachen in Python schreibt ist Einfachheit entscheidend, damit er den Schritt geht. Ich weiß – viele Leute sagen die Konzepte von git sind komplex, weil es ja auch komplexe Dinge kann und tut, aber der Einstieg ist super leicht und wenn man die komplexen Sachen irgendwann braucht ist der Aufwand sie zu lernen dann auch gerechtfertigt.

Git für Anfänger in 2 Minuten

Und hier der Beweis: Alles was der Versionskontroll-Anfänger erstmal braucht machen wir in diesem Abschnitt.

Geh in Deinen Projekt-Folder.

cd ~/programming/Raketenkontrollsoftware

Hallo git, hier hätte ich gerne ein Repository.

git init

Hallo git, ich würde gerne die folgenden Files und Folder versionieren.

git add launch.c launch.h Makefile spacecraft-configs/

Hi Git, kannst Du bitte den aktuellen Versionsstand aller vorhin hinzugefügten Files speichern (commit)?

git commit -m "Initial Version"

Git, sag mal, welche Files hab ich seit dem letzten Versionsstand eigentlich verändert oder hinzugefügt?

git status

Hallo git, ich hab ein tolles neues Feature implementiert. Die folgenden Files sind neu oder ich hab sie verändert:

git add launch.c moonlander.c moonlander.h

Git – bitte speicher den Stand dieser Dateien im Repository.

git commit -m "Add moonlander functionality"

Hey git, zeig mir doch mal, was ich in der Vergangenheit denn schon alles committed habe.

git log

Giiiiiit – ich hab Mist gebaut und nichts funktioniert mehr! Bitte bitte stell die letzte Version wieder her!

git checkout master

Danke! Dafür stehe ich ewig in Deiner Schuld!

Das war's. Mehr muss man zum Start nicht wissen. Klar – irgendwann kommt der Punkt, an dem Du zu einer ganz bestimmten Version zurück musst, diffs nutzen möchtest, Branches brauchst, GitHub entdeckst, oder einen Co-Entwickler ins Team aufnimmst. Aber bis dahin ist das echt alles, was man wirklich braucht.

Auf zu höheren Weihen

Git ist mächtig – sehr mächtig. Und deshalb gibt es viele Konzepte die man sich dann aneignen sollte, wenn man der Anfängerphase entwächst. Dazu gibt es super Doku, z.B. das Pro Git book, das ich sehr empfehlenswert finde. Wer das nicht mag, hat die Auswahl zwischen buchstäblich hunderten von anderen Quellen: Bücher, man pages, Online Tutorials, Videos, Entwickler-Foren (z.B. Stack Overflow), etc.

Ich bin jedenfalls seit Jahren ein großer Fan von git und stelle alles unter Versionskontrolle, was nicht bei drei auf dem Baum ist.