Version Control Systems

3 gute Alternativen zu Git

14.07.2023 von Matthew Tyson
Git ist nicht das einzige Version Control System auf Open-Source-Basis.
Versionskontrollsystem heißt nicht unbedingt Git. Wir zeigen Ihnen drei gute, quelloffene Alternativen.
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:

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:

3 Version Control Systems, die nicht Git sind

Fossil

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.

Mercurial

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:

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

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"):

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.