5 freie Versionskontrollsysteme im Überblick

Ein Version Control System, kurz VCS, bringt beim Programmieren Ordnung ins Code-Chaos. Doch die Software-Kategorie löst ähnlich emotionale Debatten aus, wie es bei Betriebssystemen oder Texteditoren der Fall ist. Wir stellen die wichtigsten quelloffenen und freien Kandidaten vor.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Software-Entwicklung produziert zwangsläufig einen Wust an Versionen: Es werden unterschiedliche Features entwickelt, Zwischenstände für Tests erstellt, unterschiedliche Wege ausprobiert und die parallelen Arbeiten mehrerer Entwickler zusammengeführt.

Version Control Software (VCS) ist dementsprechend für Software-Entwickler essenziell, aber auch größere Textprojekte wie Dokumentationen mit vielen Autoren können davon profitieren. VCS-Systeme sorgen dafür, dass alle Beteiligten die notwendigen Dateien bekommen, dass sie Änderungen einpflegen können, alles nachvollziehbar und revidierbar ist und natürlich alle mit derselben aktuellsten Version arbeiten.

Dafür ist auch der Umgang mit Konflikten nötig, wenn also mehrere Autoren ein und dieselbe Stelle einer Datei unterschiedlich bearbeiten (wollen). Und darüber hinaus natürlich das Versionieren selbst und somit auch die Arbeit an Abspaltungen der Hauptentwicklungslinie.

In eben diesen Kernaufgaben liegen auch die größten Unterschiede: Verteiltes oder zentrales System? Wie wird mit Konflikten umgegangen? Und nicht zuletzt: Wie kompliziert ist die Nutzung? Wir stellen im Folgenden fünf der bekanntesten Systeme und ihre Vorzüge vor.

Git

Die Plattform Git, gestartet 2005 von Linus Torvalds, muss hier im Grunde den Anfang machen. Zum Market Share gibt es zwar keine wirklich eindeutigen Zahlen, aber zumindest im Open-Source-Bereich ist Git den meisten auffindbaren Statistiken nach die klare Nummer 1. Und zwar mal seit fünf, mal seit acht Jahren, mal mit 70 oder gar 87% Marktanteil.

Nicht selten ist die Meinung vertreten, das liege nicht unbedingt an Git, sondern eher an GitHub. Dessen Popularität ist ungebrochen und Open Source Software findet man eben mittlerweile vor allem dort, nicht mehr auf Sourceforge oder Google Code.

Git ist ein verteiltes System, mit dem samt kompletter Versionshistorie offline gearbeitet werden kann, was ein großer Vorteil ist. Ein neues Repository lässt sich mit einem Befehl direkt aus einem bestehenden Ordner heraus erstellen und mit „etwas“ Konfiguration als Server für Dritte dienen. Alle Änderungen unterhalb des initialen Ordners werden ab sofort erfasst – allerdings nicht auf Dateiebene, sondern für die Repo im Ganzen.

Für Konflikte gibt es ein komplexes Merge-System, das einerseits eher triviale Konflikte sehr gut automatisch löst, andererseits bei größeren Problemen einiges an Handarbeit und Verständnis für die Git-Interna verlangt. Zudem ist Git sehr schnell und erlaubt simples Arbeiten mit Branches. Ein Bonus ergibt sich auch aus der großen Verbreitung: Git ist sehr häufig in anderen Produkten wie Editoren implementiert – das gilt zwar auch für die ältere Hauptkonkurrenz SVN, aber im Zweifelsfall findet sich eben doch eher Git.

Einer der Hauptkritikpunkte an Git ist sicherlich die steile Lernkurve: Das Konzept hinter Git ist in der Tat anfangs eher undurchsichtig, Kenntnisse werden aber an vielen Stellen der täglichen Arbeit vorausgesetzt. Zudem bringt Git reichlich Tools mit, die erst einmal erlernt werden möchten. Eine Kritik, die durchaus berechtigt ist: Durch die verteilte Natur, das Offline-Arbeiten, das einfache Branchen und das Merge-System geht mit git ein gewisser Verwaltungsaufwand einher.

Andererseits ist die Dokumentation mittlerweile sehr gut und für den Marktführer gibt es freilich reichlich Anleitungen und Artikel von Dritten. Auch hier auf Dev-Insider finden Sie ein dreiteiliges Tutorial zur Arbeit mit Git. Das Schöne an diesem Versionskontrollsystem: Einmal erlernt, ist es im Alltag sehr flexibel und im Grunde auch recht schlank.

Apache Subversion

Subversion, meist einfach SVN genannt, verwaltet bereits seit 2000 Quellcode und ist der Vorgänger von Git als deutlichem Marktführer. SVN seinerseits hatte zuvor Concurrent Versions System (CVS) abgelöst, das bereits 1990 entwickelt wurde. Zwar scheint Subversion eher auf dem absteigenden Ast zu finden zu sein, dennoch gibt es viele glühende Verfechter – schließlich ist das Konzept spürbar anders als bei Git.

Das beginnt damit, dass Subversion einen zentralen Server benötigt. Für kleinere Projekte empfinden das nicht wenige Nutzer als besser, als die gesamten Daten auf jedem einzelnen Rechner vorzuhalten. Offline-Arbeit ist damit aber nur bedingt möglich. Letztlich ist es eine Frage der Situation, des Teams und vor allem der Organisation, ob nun Peer-to-Peer oder Client-Server die bessere Wahl ist. Wer mit vielen großen Binärdateien arbeitet, etwa bei Multimedia-Projekten, verteilt per Git beispielsweise enorme Datenmengen!

Auch beim zweiten großen Unterscheidungspunkt kann SVN punkten. Statt nur auf die Merge-Strategie zum automatischen/manuellen Verschmelzen von Konflikten zu setzen, gibt es hier auch noch die Lock-Strategie: Dateien/Ordner lassen sich für andere sperren, sobald sie von einem Nutzer bearbeitet werden. Damit lassen sich Konflikte von Vornherein vermeiden. Natürlich auf Kosten der Mitarbeiter, die just nicht an die Datei kommen; Git erlaubt grundsätzlich allen Teilnehmern alles.

Oft ein Vorteil von Subversion: Änderungen werden auf Ordner- und Dateiebene festgehalten. Wenn Sie also eine Datei umbenennen, behält sie ihre komplette Versionshistorie, während Git ein neues Objekt mit neuer Historie anlegen würde. Das entspricht zumindest eher der Erwartung nicht mit VCS vertrauter Nutzer. Überhaupt arbeitet SVN teils “näher an Dateien”. Branches sind in SVN Ordner, in Git lediglich Referenzen auf Änderungen in der Versionshistorie, ab denen eben abgezweigt wird.

Alles in allem gilt SVN als (anfangs) nutzerfreundlicher und wird auch mal für die Dokumentenverwaltung von Nicht-Entwicklern eingesetzt. Persönliche Anmerkung: Andererseits wird auch dieses Dokument in einem Git-Repo verwaltet – Git ist also auch für triviale Aufgaben alltagstauglich und zuverlässiger als manch eine Synchronisierungslösung.

Mercurial

Mercurial ist Git in mancherlei Hinsicht ähnlich: Es stammt ebenfalls aus 2005, sollte ebenfalls ein anderes System (BitKeeper) ersetzen und für den Linux-Kernel genutzt werden, ist ebenfalls ein verteiltes System und auch die Konfliktlösungsstrategien sind ähnlich. Das System wird übrigens oft auch nur Hg genannt, das chemische Symbol für Quecksilber (Mercury).

Die grundsätzliche Arbeit ist bei Git und Mercurial sehr ähnlich, aber es gibt einige deutliche Unterschiede. Beispielsweise beherrscht Mercurial die Kunstform des simplen „Undo“-Befehls, also des Zurücknehmens von Operationen – bei Git ist das nur mit viel Hintergrundwissen und Tipperei zu erledigen.

Mercurial bringt außerdem einen eigenen Webserver mit, der es einfacher macht, Repositories Dritten zur Verfügung zu stellen. Weitere technische Unterschiede zu Git sind zum Beispiel die Programmiersprache (hier Python), globale Tags für mehrere Repos, nativer Windows-Support, Merge- und Lock-Strategie oder bessere interne Hilfe. Andererseits gibt es bei Mercurial auch aus Subversion bekannte Features, allem voran das Behalten der Versionshistorie bei Verschiebe- und Kopiervorgängen.

In Diskussionen kommt Mercurial sehr oft sehr gut weg, unter anderem weil der Einstieg vielen deutlich einfacher fällt und Git an der einen oder anderen Stelle vielleicht doch etwas umständlicher zu nutzen ist. Insofern ist Mercurial technisch gesehen definitiv ein Tipp für Einsteiger – dem entgegen steht jedoch die schiere Marktpräsenz von Git. Einen Git-Nutzer findet man vermutlich in jedem Bus.

GNU Bazaar

Einen Bazaar-Nutzer zu finden dürfte deutlich schwieriger werden; dabei handelt es sich hierbei ebenfalls um ein verteiltes, mit Python programmiertes System aus dem Jahr 2005, hinter dem mit Canonical ein starker Sponsor steht. Zudem ist es noch Teil des GNU-Projekts.

Bazaar hat darüber hinaus auch noch einige interessante Features. Beispielsweise funktioniert es wahlweise rein distribuiert oder mit einem zentralen Server – oder gar beides gleichzeitig. Bazaar kann sogar aus Subversion-Repos Branches erstellen, bearbeiten und wieder zurück an Subversion geben. Aus Git und Mercurial kann immerhin gelesen werden. Auch der Im- und Export ganzer Historien in/aus diversen VCS-Systemen ist möglich.

Doch leider scheint Bazaar nur noch ein Nischenprodukt zu sein: Bereits 2014 habe die beiden populären Bazaar-Nutzer GNU Emacs und Bugzilla auf Git umgestellt, weil die Entwicklung nicht mehr voran ging – kurz zuvor hatte der Hauptentwickler Canonical verlassen. Das letzte Release stammt von 2016, seitdem tröpfeln nur hier und da ein paar Beiträge ein. Bazaar mag für kleinere Projekte, die mit anderen VCS-Tools zusammenarbeiten müssen noch interessant sein, wirklich empfehlen kann man es aber nicht mehr.

Fossil

Fossil stammt ausnahmsweise mal nicht aus 2005, sondern aus 2006 – eine gute Zeit für VCS. Fossil ist explizit für die Entwicklung von SQLite gedacht und speichert Daten auch in einer internen SQLite-Datenbank. Das ist schon mal ein großer Unterschied zu Gits Datei-Ansatz. Zwar ist Fossil ebenfalls ein verteiltes System, arbeitet jedoch mit einem zentrale Repository, auf dem alle Arbeiten aller Entwickler zusammengeführt werden.

Bei Git hingegen arbeitet jeder Entwickler mit eigenen privaten Branches, die unter Umständen niemals jemand anderes als der Entwickler selbst zu sehen bekommt. Fossil verfolgt einen wesentlich zentralistischeren Ansatz, da SQLite im Wesentlichen von nur drei Personen gepflegt wird, während der Linux-Kernel via Git von Tausenden Entwicklern gespeist wird.

Auf Feature-Seite sticht Fossil durchaus hervor, da es neben dem eigentlichen VCS auch noch ein Ticketsystem, Wiki, Dokumentations und Forum beinhaltet. Und ganz wichtig: Ein integrierter Webserver macht das Erstellen einer Entwickler-Website deutlich einfacher als zum Beispiel bei Git. Bei Git müssen allerlei Tools und Konfigurationen eingestellt werden, was schon mal Stunden und Tage dauern kann, bei Fossil geht das automatisiert binnen Minuten.

Aber auch beim Versionieren selbst kann Fossil durchaus punkten. Zum einen ist Fossil ein einziges Tool mit vielen Optionen und komplexen Operationen, während Git aus vielen kleinen Tools besteht – die im Zweifel vom Nutzer selbst “richtig” kombiniert werden müssen. Zum anderen gilt auch Fossil als einsteigerfreundlicher als Git.

Eine Frage der Organisation sein

Letztlich dürfte es vor allem eine Frage der Organisation sein, ob der komplett verteilte Ansatz von Git oder eher zentralistische Ansätze wie bei Fossil oder Subversion besser passen. Schaut man sich die allgemeinen Kritiken an, könnte man zu dem Schluss kommen, dass Git in der Tat eher wegen GitHub der (scheinbar) unangefochtene Marktführer ist. Für viele Entwickler scheint Git vor allem ein verschachteltes Tool für Nerds, flexibel, aber umständlich zu bedienen und fehleranfällig.

Andere mögen die komplett verteilte Natur nicht, da durch private Branches und Offline-Arbeit natürlich schnell Chaos in der Codebasis entstehen kann, das dann erst mal wieder aufgelöst werden will. Wer jedoch bereit ist, sich intensiv mit Git zu beschäftigen, bekommt langfristig ein extrem schnelles Werkzeug an die Hand, mit dem sich so ziemlich alles bewerkstelligen lässt – und sei es mit Hilfe von Dritten (etwa Zugriffsrechte).

Eines ist jedenfalls klar: Je mehr „Laien“ am Projekt mitarbeiten sollen, beispielsweise Nicht-Entwickler in einem Dokumentationsprojekt, desto problematischer ist Git. Wer auf dem leeren Papier ganze Python-Programme schreibt, dürfte hingegen auch mit Git keine Probleme haben. Mercurial scheint eine gute Alternative, die hier und da ein wenig zwischen Git und Subversion steht.

Klar ist aber auch: Je größer die Projekte sind, desto feiner sind auch die Anforderungen an Details – und im Detail, etwa bei Dateiformaten oder dem genauen Ablauf bei Konflikten, unterscheiden sich die Tools dann doch wieder alle deutlich. Nicht umsonst ist die Diskussion wie anfangs erwähnt hitzig – vieles im VCS-Umfeld fällt schlicht und ergreifend in die Welt der Meinung.

Git-Tutorial: Git und die wichtigsten Befehle kennenlernen

Modellgetriebene Entwicklung

Versionierung: Die Herausforderung bei der Modellierung

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.

(ID:45979745)