Es ist (nicht nur) beim Programmieren hilfreich, wenn man einfach auf ältere Versionen des Quelltextes einer Software zurückgreifen kann, selbst wenn man alleine programmiert. So kann man dann zum Beispiel nachvollziehen, wann man einen Fehler eingebaut hat (natürlich aus Versehen). Oder man stellt nach einiger Zeit fest, dass eine ältere Version doch „besser“ ist. Dazu verwendet man eine Software zur Versionsverwaltung. Programmiert man mit anderen, so verhindert die Versionsverwaltung zum Beispiel, dass Änderungen des einen aus Versehen durch einen anderen überschrieben werden. Ein Versionsverwaltung leistet noch viel mehr. Wen das interessiert muss nur den Begriff in die Suchmaschine der Wahl eingeben.

Versionsverwaltungssoftware gibt es etwa seit den 1970er Jahren. So eine Software ist optimiert auf die jeweils aktuelle Art Software zu erstellen. In den 1970er Jahren waren dieses hauptsächlich zentrale Computer, mit denen man über ein Terminal verbunden war. Als in den 1980er Jahren die Zeit der lokal vernetzten PCs begann, wurde auch eine andere Art der Software zur Versionsverwaltung verwendet. Nun wurden die Versionen auf einem zentralen Computer („Server“) abgelegt und jeder Computer eines Softwareentwicklers lud sich die letzte gültige Version herunter, denn Festplattenspeicherplatz war damals knapp. Als das Internet in das Leben der Softwareentwickler trat, wurde dieses Modell zunächst beibehalten.

Sehr schnell stellten viele Personen fest, dass dieses Modell der Versionsverwaltung sich nicht so gut mit einer internetbasierten Softwareentwicklung verträgt. Aber, es gibt nicht einmal das eine Modell einer internetbasierten Softwareentwicklung, auch wenn sich die Modelle in vielen Aspekten ähneln.

Die Software Mercurial wurde zum Beispiel entwickelt, um Probleme bei der sehr verteilten Entwicklung des Linux-Kernels zu lösen, an dem Tausende von Personen aus unterschiedlichsten Organisationen arbeiten. Auch die Person, die den Linux-Kernel begonnen hatte zu programmieren und die den gesamten Quellcode zusammenführt, Linus Torvalds, erkannte zeitgleich und (vermutlich) unabhängig das Problem und entwickelte Git. Nachdem die Personen um Mercurial erkannten, dass ihre Software nicht zur Entwicklung des Linux-Kernels genutzt wird (Linus Torvalds trifft zur Not die Entscheidung), wurde Mercurial auch an die Bedürfnisse anderer Projekte angepasst. So mag zwar Mercurial auf einer technischen Ebene nicht so flexibel wie Git zu sein, dafür ist es wesentlich besser zu bedienen. Es gibt noch andere Software zur Versionsverwaltung, etwa Fossil. Auch hier hat ein Entwickler einer anderen Software (der am weitest verbreiteten Datenbanksoftware SQLite) zunächst für seine Bedürfnisse eine Software entwickelt. SQLite wird nicht von Tausenden Personen zeitgleich entwickelt, sondern von einem eingespielten Team.

Nun setzt sich nicht unbedingt die „beste“ Software durch, sondern meist gibt es externe Ereignisse, die einer Software zum Durchbruch verhelfen. Im Fall von Git war das die kostenlose Verfügbarkeit von GitHub. Git und Mercurial verwalten nämlich nur die Versionen von Dateien, aber eine adäquate Softwareentwicklung benötigt mehr. So ist eine Verwaltung der Aufgaben wichtig, wie auch die Ablage interner Dokumentationen. Im Fall von Git kommt noch hinzu, dass viele außerhalb der Entwicklung des Linux-Kernels nicht mit dem Mail-basierten Austausch von Aktualisierungen klarkommen. Diese Marktlücke hat GitHub erkannt, sich auf Git spezialisiert, und notwendige Erweiterungen über einen zentralen Dienst zusammengefasst. Dazu noch etwas Gamification und die Möglichkeit, dass Accounts einander „folgen“ und fertig ist das Facebook für Entwickler. Dies hat Git zum fast vollständigen Durchbruch verholfen, obwohl es ja nur die Art und Weise unterstützen soll, wie der Linux-Kernel entwickelt wird. Trotzdem ist es inzwischen eine Art Monopolist, wie es auch IBM für die Mainframes oder Windows für PCs ist und wie es in vielen Bereichen Java noch ist.

Auch ich habe mich für meine projektbasierte Lehre dem Druck gebeugt. Bis vor einigen Jahren verwendeten die Studenten Mercurial. Dann begannen die Klagen, dass Mercurial nicht so gut wie Git von den integrierten Entwicklungsumgebungen unterstützt wird. Sie hatten wohl auch Schwierigkeiten, bei Problemen geeignete Suchanfragen zu stellen. Ich habe dann auf Git und GitLab umgestellt. GitLab lizenziert seine Software sogar in der größten Ausbaustufe („Ultimate“) kostenlos an Hochschulen. In der kleinsten ist es frei verfügbar. Als Zusatznutzen kann man auch weitergehende Aspekte der Softwareentwicklung praktisch lehren, zum Beispiel „DevOps“.

Wenn meine Studenten Git nutzen, dann nutze ich das auch. Zum einen sollte man sowieso immer das auch selbst tun, was man von anderen verlangt. Zum anderen kann ich durch meine eigenen Erfahrungen den Studenten besser Hilfestellungen geben. Auch wenn ersteres im Falle von Git manchmal schmerzhaft war.

Git ist nämlich nur in Teilen eine Software zur Versionsverwaltung, im Sinne einer revisionssicheren Ablage früherer Versionen. Tatsächlich versteht man Git besser, wenn man es als eine Art verteiltes „Content Management System“ für Texte auffasst. Die Argumentation dafür geht in etwa so, dass (nicht nur) Linus Torvalds nicht alle Irrungen und Wirrungen der anderen Entwickler sehen möchte und es daher sinnvoll sein soll, solche Unschönheiten gewissermaßen wegzuretuschieren. Wer darin nicht geübt ist, kann aus Versehen Inhalte löschen oder sogar den ganzen Datenbestand der Versionsverwaltung nutzlos machen. Deshalb ist Git gerade für Anfänger schmerzhaft. Aber auch erfahrene Entwickler bekommen damit immer wieder Probleme.

Auch um den Studenten ein Beispiel zu geben, im Wortsinne, nutze ich Git für so gut wie alle meiner eigenen Softwareprojekte. Die Software zum Agilen Studieren wird ebenso von Git / GitLab verwaltet, wie die Software zur automatisierten Gruppeneinteilung, letztere ist zusätzlich auf GitHub zu finden. Ich nutze das gleiche GitLab, wie auch die Studenten.

Diese Website, wie auch die zum Agilen Studieren ist ebenfalls mittels Git versioniert. Hierfür verwende ich, wie für meine anderen hochschulferneren Projekt, nicht das hochschulinterne GitLab, sondern eine kleinere Software namens Gitea, installiert auf einen kleinen Server in meinem Arbeitszimmer. GitLab ist eine komplexe Software, nicht ganz einfach zu installieren und in Betrieb zu halten. An der Hochschule kümmert sich ein Mitarbeiter darum. Die Ersteinrichtung, die in unserem Kontext etwas komplexer ist, dauerte selbst mit Hilfe einer fähigen studentischen Hilfskraft mehrere Monate. Im privaten Kontext ist mir das zu aufwendig.

Git scheint sich dank GitHub durchgesetzt zu haben, schließlich sind auch Personen in der Softwareentwicklung soziale Wesen. Offenbar braucht jede Gruppe ihr Facebook / LinkedIn. Schließlich sind die Netzwerkeffekte enorm. Da wundert es mich kaum, wie Personen reagieren, wenn man Alternativen ins Gespräch bringt, ob nun für Git/GitHub, Markdown, Java, Windows, VHS, IBM. Das manchen als Tabubruch. Mich amüsiert dann im Fall von GitHub, wie dieser als zentraler Dienst das Konzept der Verteilung von Git / Mercurial / Fossil & Co ad absurdum führt.

Dabei merke ich an mir selbst, und beobachte an vielen Entwicklungsteams, wie sehr das Modell von Git nicht zu alternativen Vorgehensmodellen passt. Als Einzelprogrammierer, als studentische Projektgruppe, als unternehmensinternes Entwicklungsteam geht man doch anders vor, wie bei der Entwicklung des Linux-Kernel, auch wenn man gerne dessen Erfolg wiederholen möchte. Gerne wird dann argumentiert, dass ein Entwicklungsteam ja bei Erfolg das Linux-Modell übernehmen könnte und dass dann Git „skalieren“ würde. Mir scheint dieses Argument dem zu ähneln, man möge doch einen Bus kaufen, denn man wisse ja nie, wie viele Personen man einmal transportieren müsse.

Aber das ist ein anderes Thema.