Der primäre Zweck einer Versionsverwaltung ist das Archivieren von Dateien.

Dadurch ist es möglich, die Versionsgeschichte, also wer was wann geändert hat, nachzuvollziehen

und bei Bedarf auch alte Versionen wiederherzustellen.

Im Bereich der Softwareentwicklung ist das keineswegs eine Neuerfindung, sondern wird

schon seit einem halben Jahrhundert eingesetzt.

Das 1972 von Bell Labs entwickelte Source Code Control System war das erste wirklich

relevante Versionsverwaltungssystem.

Da zu dieser Zeit Speicherplatz noch etwas kostbar war, hat es die erste Version und

darauf aufbauend nur die Änderungen gespeichert, und zwar in einem versteckten Unterordner.

Wenn nun aber die Versionsgeschichte länger wird, also viele Änderungen dazukommen, dann

kann das Durcharbeiten schon seine Zeit dauern, insbesondere da meist nur die neuesten Versionen

die interessant sind.

Jürgen Kleinüter hat da mit unserer DNS-Verwaltung an der Uni auch das passende Beispiel, weshalb

mit der Zeit auf das Revision Control System umgestellt wurde.

Dieses war zwar etwas einfacher gestrickt, hatte zum Beispiel keine Prüfsumme mehr,

speicherte aber vor allem nur die letzte Version und delt das zu den vorherigen Änderungen

und war damit deutlich performanter.

Und ja, RCS wird bei uns an bestimmten Orten immer noch verwendet, insbesondere um lokale

Dateien, vor allem Konfigurationsdateien zu tracken.

Aber schon in den 80ern kam die Anforderung, Dateien nicht nur lokal, sondern projektbezogen

über Netzwerk zu versionieren, was die Weiterentwicklung zum Concurrent-Version-System begründete.

Dort konnten an einer zentralen Stelle im Netzwerk mehrere Dateien gespeichert werden,

allerdings waren Revisionen weiterhin nur auf einzelne Dateien bezogen.

Dieses System erfreute sich insbesondere in der aufkommenden OMSource-Bewegung großer

Beliebtheit, wurde aber nach und nach von dem um die Jahrtausendwende entwickelten Subversion

abgelöst, welches zwar das Konzept einer zentralen Stelle adaptierte, nun aber gemeinsame

Revisionen für mehrere Dateien einführte und im Gegensatz zu den Vorgängen auch beim

Umbenennen und Verschieben von Dateien die Versionsgeschichte beibehielt.

Im Jahr zuvor wurde jedoch mit dem ursprünglich proprietären Bitkeeper das erste bedeutende

verteilte Versionsverwaltungssystem veröffentlicht.

Das Konzept war nun für freie Software relativ interessant, weil man sehr einfach Forks erstellen

und die Entwicklung eines Projektes in unterschiedliche Richtungen vorantreiben konnte.

Die dahinterstehende Firma Bitmover hat das auch erkannt, um mittels einer umstrittenen

Lizenz OMSource-Projekten die kostenlose Nutzung erlaubt, jedoch unter der Bedingung,

sich einige Zeit nicht an der Entwicklung konkurrierender Versionsverwaltungssysteme

zu beteiligen.

Aber natürlich dauerte es nicht lang, bis mit Source Puller eine kompatible OMSource-Alternative

begonnen wurde, was dann schlussendlich dazu führte, dass 2005 alle kostenlosen Lizenzen

beendet wurden und viele OMSource-Projekte nun ein Problem hatten.

Das traf auch Linux, das seit 2002 auf Bitkeeper aufgesetzt hatte, nach 10 Jahren komplett

ohne Versionsverwaltungssystem.

Obwohl zu dieser Zeit unter anderem mit Mercurial und Basar auch weitere frei verteilte Versionsverwaltungssysteme

das Licht der Welt erblickten, hat Linus Torvalds höchstpersönlich im April 2005

mit Git ein eigenes freies Tool begonnen.

Für die erste Version brauchte er nur ein paar Tage und bereits nach drei Monaten wurde

der komplette Linux-Kernel damit verwaltet.

Und da Git auch sehr gut auf unsere Bedürfnisse zugeschnitten ist, wollen wir es auch für

die Übung verwenden.

Die Hauptmerkmale von Git sind unter anderem die nicht-lineare Entwicklung mittels verschiedener

Zweige, welche normalerweise für einzelne neue Features verwendet werden, sowie die