Foto: Premium Art - shutterstock.com
Die Versionskontrollsoftware Git wurde ursprünglich entwickelt, um den Quellcode des Linux-Kernels zu managen. Seither hat sich das Open-Source-Tool zum Standard entwickelt, wenn es darum geht, Quellcodebasen für Open- und auch Closed-Source-Projekte zu managen. Dennoch gibt es gute Gründe, nach alternativen Version Control Systems Ausschau zu halten - zum Beispiel:
das recht komplexe Modell von Git, wenn darum geht, Code in Staging-Umgebungen zu verfrachten;
den mitunter verwirrenden Befehlssatz von Git;
grafische Benutzeroberflächen und Frontends, die die Komplexität nur verschleiern statt sie zu reduzieren;
mögliche Probleme, bestimmte Files in Projekten zu tracken, beispielsweise große Binaries und komplexe Datenstrukturen.
Falls Sie sich in einem dieser Punkte wiedererkannt haben, haben wir gute Nachrichten: Es gibt mehrere gute, quelloffene Versionskontrollsysteme, die nicht Git heißen - und teilweise auch erweiterte Funktionalitäten bieten. In diesem Artikel werfen wir einen Blick auf die drei größten Git-Konkurrenten, ihre Funktionen und Anwendungsfälle:
Fossil,
Mercurial und
Subversion.
3 Version Control Systems, die nicht Git sind
Dwayne Richard Hipp ist als Schöpfer des quelloffenen Datenbanksystems SQLite bekannt, eines der meistgenutzten Softwareprodukte der Welt. Für die Quellcode-Kontrolle nutzt er allerdings nicht Git, sondern das ebenfalls von ihm entwickelte Versionskotrollsystem Fossil, das darauf konzipiert ist, die Entwicklung von SQLite zu unterstützen.
Der größte Unterschied zwischen Fossil und Git: Letzteres dient nur dazu, Änderungen an einer Codbasis über ein virtuelles Dateisystem zu tracken. Fossil ist eher mit Bitbucket vergleichbar: ein selbstgehostetes System, das nicht nur Änderungen verfolgt, sondern auch Ticketing und Bugtracking, Wikis, Dokumentation sowie Live-Diskussionen für ein Projekt integriert. Davon abgesehen verwendet Fossil eine ähnliche Datenstruktur wie Git, speichert Daten jedoch in einer SQLite-Datenbank. Das ermöglicht es, Abfragen über Änderungen besonders schnell zu bearbeiten.
Sein Design und die genannten Unterschiede machen Fossil nach Auffassung seines Schöpfers vor allem für kleinere Teams zu einem guten Tool. Auf der Projektseite finden Sie detaillierte Hinweise zu einer Vielzahl verschiedener Themenbereiche - etwa dem Wechsel zwischen Git und Fossil, sowie dazu, Projekte zwischen den beiden Version Control Systems zu synchronisieren.
Im Jahr 2005 zog das proprietäre Versionskontrollsystem BitKeeper seine freie Lizenz für den Linux-Kernel zurück. In der Folge entstanden zwei Ersatzlösungen: Git und Mercurial. Letzteres machte in Sachen Linux-Kernel-Projekt nicht das Rennen, wurde aber beispielsweise von Entwicklern bei Facebook, Mozilla, dem W3C oder im Rahmen des PyPy-Projekts eingesetzt.
Konzeptionell funktionieren Mercurial und Git auf die gleiche Weise: Sie verwenden beide einen Graphen, der die an einer Codebasis vorgenommenen Änderungen abbildet. Allerdings ist der Mercurial-Befehlssatz kleiner und so für gängige Use Cases einfacher zu beherrschen. Ein weiterer wesentlicher Unterschied zu Git ist die Art und Weise, wie Branches in einem Source Tree funktionieren: Wenn Sie in Git einen Branch ändern, wird Ihr aktuelles Verzeichnis entsprechend umgeschrieben. In Mercurial gibt es mehrere verschiedene Branching-Strategien:
Sie können das Repository in ein anderes Verzeichnis klonen und an diesem als Branch arbeiten.
Sie können verschiedene Punkte in einem Änderungssatz mit Lesezeichen versehen und diese als Grundlage für Änderungen verwenden.
Sie können einen "named" Branch verwenden, bei dem der Name zu einem permanenten Teil des Änderungssatzes gemacht wird - nützlich, da der Name bei jeder zukünftigen Änderung an diesem Branch berücksichtigt wird, es aber nicht zu Chaos führen kann.
Sie können anonyme, unbenannte Branches erstellen, die für schnelle Änderungen praktisch sind (wenn Sie sie in Ihren zugehörigen Notizen richtig erklären).
Mercurial bietet darüber hinaus einen Erweiterungsmechanismus, der es ermöglicht Drittanbieter-Code direkt in das Versionskontrollsystem zu integrieren. Diverse Extensions gehören ebenfalls zum kostenlosen Paket.
Subversion (oder SVN) ist ein Projekt der Apache Foundation. Ins Leben gerufen wurde es bereits im Jahr 2000. Apache, FreeBSD und SourceForge gehören zu den bekanntesten Nutzern der Git-Alternative.
Der Hauptunterschied zwischen SVN und Git: Subversion ist zentralisiert - das Repository wird also an einem definierten Ort gespeichert. Mitwirkende erstellen in der Regel keine lokalen Kopien der Codebasis, sondern arbeiten an Code-Branches in der zentralisierten Kopie. Administratoren können Subversion-Repositories mit sehr detaillierten Zugriffskontrollen ausstatten, so dass die Beiträge nicht manuell sortiert werden müssen.
Die zentralisierte Natur von SVN ist sowohl Segen als auch Fluch: Letzteres weil man einen guten Backup-Plan braucht, wenn dem zentralen Repository etwas zustößt. Code-Verzweigungen werden zudem weniger elegant gehandhabt: Sie sind im Grunde physische Verzeichnisse mit diskreten Kopien des Codes, anstelle des virtuellen Dateisystemmodells von Git.
Dadurch, dass jeder Entwickler eine Kopie des Codes behält, sind Projekte allerdings andererseits auch widerstandsfähiger gegen Ausfälle (oder rachsüchtige Systemadministratoren). Und das zentralisierte Modell sorgt dafür, dass Sie weniger Schritte kennen müssen, wenn Sie an einer Codebasis arbeiten - auch wenn diese einzelnen Schritte höhere Anforderungen stellen. Zudem kommt Subversion dank eines Differenzierungsalgorithmus auch besser mit großen Binärdateien zurecht.
SVN eignet sich vor allem für Projekte, bei der eine engmaschige Kontrolle von Source Code notwendig ist: Bei Git kann die Historie eines Repository rückwirkend geändert werden. Das ist hier nicht möglich - das Repository ist die Single Source of Truth.
GitHub selbst unterstützt bislang Subversion-Repositories, wird das aber ab Januar 2024 einstellen.
Welches Versionskontrollsystem ist für Sie geeignet?
Um Ihnen die Entscheidungsfindung zu erleichtern, hier noch einmal ein zusammenfassender Blick auf die Vorteile der drei vorgestellten Git-Alternativen (im Vergleich zum "Original"):
Fossil bietet eine All-in-One-Experience, die einer schlüsselfertigen Code-Hosting-Plattform gleichkommt - inklusive Ticketing und Diskussion, während Git ausschließlich darauf fokussiert, Änderungen über eine zu tracken.
Mercurial ist durch seinen Erweiterungsmechanismus von Haus aus modifizierbar, während sich das bei Git nur mit Hilfe externer Tools bewerkstelligen lässt.
Subversion bietet dank Zentralisierung ein einfacheres, konzeptionelles Modell und eine bessere Kontrolle über den Quellcode - im Gegensatz zu den komplexen Konzepten und der dezentralisierten Dateiverwaltung von Git.
Falls keine der genannten Alternativen Sie weiterbringt, tun es vielleicht diese nützlichen Git-Tricks in Videoform:
(fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.com.