Versionskontrollsysteme im Vergleich

Git oder Mercurial: Was sollte man nutzen?
Kommentare

Git oder Mercurial? Welches Versionskontrollsystem ist besser für mein Team geeignet? Welches System sollte ich als Versionskontroll-Neuling wählen? Ein Überblick über die wichtigsten Fakten zu Git und Mercurial.

Seit ihrer Einführung im April 2005 scheiden sich die Geister an Git und Mercurial. Beide Systeme haben schon immer ihre Unterstützer und Hardcore-Fans um sich geschart, die ihr Lieblingssystem mit beinahe religiösem Eifer verteidigen. Die Diskussionen in Entwicklerforen bestehen darum häufig aus sehr subjektiven Meinungen. Das macht es ziemlich schwierig, zu einer fundierten Entscheidung für das eine oder das andere System zu kommen.

In den letzten paar Jahren hat sich Git für viele Entwickler zum Standard unter den Versionskontrollsystemen entwickelt. Vor allem in der Open-Source-Community kann man mit ziemlicher Sicherheit davon ausgehen, dass sich die meisten Entwickler in den Foren für Git aussprechen. Git hat eine große Anhängerschaft aus Nutzern und Unterstützern, die eine loyale Community bilden. Mercurial ist im Vergleich dazu nicht einmal annähernd so stark gewachsen, hat allerdings auch seine Anhänger und wird von vielen großen und bekannten Unternehmen wie Facebook, Mozilla und dem World Wide Web Consortium (W3C) verwendet.

Gemeinsamkeiten

Sowohl Mercurial als auch Git sind verteilte Versionskontrollsysteme (DVCS). Im Kern erlauben es DVCS mehreren Entwicklern, an derselben Codebasis zu arbeiten, ohne ständig Zugang zum gleichen Netzwerk haben zu müssen. Alle Entwickler arbeiten an ihren eigenen lokalen Kopien (Clones) des Code Repositorys. Diese werden zusammengeführt, nachdem die vorgesehenen Änderungen vorgenommen wurden. Darum ist der Vergleich von Git und Mercurial etwas komplizierter als der von Git und Subversion, einem zentralen Versionskontrollsystem.

© Mercurial; Screenshot von https://www.mercurial-scm.org/wiki/

© Mercurial; Screenshot von https://www.mercurial-scm.org/wiki/

Darüber hinaus handelt es sich sowohl bei Git als auch bei Mercurial um Open-Source-Versionskontrollen. Das bedeutet, dass Entwickler kontinuierlich an den Systemen arbeiten, indem sie neue Features und Extensions dafür entwickeln. Wer also eine bestimmte Funktion in einem der Systeme benötigt, kann sie einfach selbst bauen und dann mit anderen teilen – oder jemanden darum bitten, das Feature umzusetzen.

Am Ende machen Git und Mercurial das Gleiche: Sie speichern den Versionsverlauf des Codes. Unabhängig davon, welches der Systeme man wählt, hat man sich also für ein mehr als solides Versionskontrollsystem entschieden.

Es gibt jedoch auch einige offensichtliche Unterschiede zwischen Git und Mercurial. Die Diskussion dreht sich in weiten Teilen um die Usability, die notwendige Fachkenntnis und die Sicherheit der zwei Systeme. In den folgenden Abschnitten werden wir die wichtigsten Unterschiede beleuchten, sodass jeder selbst zu einer Entscheidung in der Diskussion über Git und Mercurial kommen kann.

Lesen Sie auch „Git vs. Subversion (SVN): Welches Versionskontrollsystem sollten Sie nutzen?„.

Einfachheit

Einen der größten Unterschiede zwischen Git und Mercurial stellen die unterschiedlichen Level an Fachwissen dar, die notwendig sind, um mit den Systemen zu arbeiten. Kurz gesagt: Git ist komplexer. Wer damit arbeiten will, muss das System in- und auswendig kennen, um sicher und effektiv damit umgehen zu können. Mit Git kann ein schlampiger Entwickler dem ganzen Team großen Schaden zufügen! Außerdem gilt die Dokumentation von Git als schwerer verständlich. Code-Hosting-Plattformen wie Deveo reduzieren einige der potenziellen Probleme, die unerfahrene Entwickler verursachen können. Mit Deveo können beispielsweise Änderungen an der History und das Löschen von Branches verhindert werden.

Mercurial könnte also für ein Team die bessere Wahl sein, wenn es aus wenig erfahrenen Entwicklern besteht oder Kollegen ohne technischen Hintergrund zum Team gehören. Die Syntax des Systems ist einfacher, die Dokumentation besser. Außerdem arbeitet Mercurial so, wie ein Tool funktionieren sollte: Man muss nicht darüber nachdenken, während man es benutzt. Mit Git kann es hingegen passieren, dass man Zeit investieren und in verschiedenen Foren nachfragen muss, um herauszufinden, warum das System irgendein unerwartetes Verhalten zeigt. Wenn man aber einmal mit Git vertraut ist, ist das System sehr flexibel.

Kommandos

Wer sich für Git entscheidet, sollte ein intuitives GUI dazu auswählen. Git mit der Kommandozeile (CLI) zu verwenden, kann gerade zu Anfang ein echter Albtraum sein. Git-Kommandos sind umfangreich und kommen mit vielen Optionen daher, die die Komplexität natürlich erhöhen. Immerhin hat Git weniger Kommandos als Mercurial und man kann jederzeit eigene Aliase für Git Kommandos einführen, die die Arbeit deutlich vereinfachen.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

Die Kommandos in Mercurial sind grundsätzlich ziemlich einfach zu erlernen und zu benutzen. Die Anzahl möglicher Kommandos ist höher als in Git und sie sind zugleich spezifischer. Die ursprünglichen Entwickler von Mercurial wollten sicher gehen, dass jedes Kommando nur eine Aufgabe erfüllt – und zwar sehr zuverlässig.

Sicherheit

Eine Besonderheit in der Diskussion über Git und Mercurial ist, dass man für jedes der beiden Systeme argumentieren kann, dass es sicherer ist als das andere – und zwar ohne sich zu widersprechen. Das liegt an den unterschiedlichen Kompetenzleveln, die für die Nutzung der Systeme notwendig sind: Mercurial ist auch dann sicher, wenn es von wenig erfahrenen Nutzern verwendet wird, während Git Wege zur besseren Absicherung für diejenigen bietet, die sich gut damit auskennen.

In Mercurial ist es standardmäßig nicht möglich, die History zu verändern. Um das zu ermöglichen, muss die Option bewusst aktiviert werden. Git erlaubt es hingegen allen beteiligten Entwicklern, den Versionsverlauf zu verändern, was zu großen Schäden am Projekt führen kann. Es bedeutet jedoch auch, dass Git eine bessere Kontrolle über die History bietet, während mit der Basiseinstellung von Mercurial nur der letzte Commit per „hg rollback“ änderbar ist.

Darüber hinaus speichert Git jede Änderung für 30 Tage im Reflog, sodass man beispielsweise die Commit Message des letzten Commits ändern und das 30 Tage lang ganz einfach wieder rückgängig machen kann. Das geht allerdings erst mal nur lokal, weil die Änderungen nicht automatisch an den Server übergeben werden. Nach 30 Tagen werden die Änderungen per Garbage Collection aus dem Log gelöscht, sodass man danach nicht mehr darauf zurückgreifen kann.

Branching

Branching bedeutet kurz gesagt, dass man in einem Zweig des Projekts an Dateien arbeitet, die man verändern möchte. Mit Branches kann an mehreren Versionen des Projekts zur selben Zeit gearbeitet werden, die am Ende wieder zusammengeführt werden, ohne damit die Codebasis zu zerstören.

Einer der wichtigsten Gründe dafür, dass Entwickler sich für Git aussprechen, ist das sehr effektive Branching-Modell. Branches sind in Git nur Referenzen auf einen bestimmten Commit, sodass sie sehr leichtgewichtig sind und zugleich ein mächtiges Werkzeug darstellen. In Mercurial funktioniert Branching etwas anders als in Git. Zweige in Mercurial sind linear entstandene, konsekutiv hinzugefügte Changesets. Mit Changesets (csets) ist ein komplettes Set an Änderungen gemeint, das an einer Datei in einem Repository vorgenommen wurde. Mercurial bettet die Branches also in die Commits ein, wo sie für immer gespeichert werden. Das bedeutet, dass Branches in Mercurial nicht entfernt werden können, weil dafür die History geändert werden müsste. Branching kann somit in Mercurial mühsamer werden als in Git.

Zuletzt muss noch das Risiko genannt werden, Code in Mercurial an den falschen Branch zu übergeben. Vor allem dann, wenn die Branches keine eindeutigen Namen habe, kann das vorkommen. In Git lässt sich das leicht verhindern. Somit ist die Branching-Struktur also ein wichtiger Faktor im Kampf zwischen Git und Mercurial. Man könnte sagen, dass Git dafür die bessere Lösung hat. Während Mercurial leichter zu erlernen und zu verwenden ist, könnte das Branching-Modell hier zu Problemen führen.

Gits Staging Area oder Index

Die Staging Area, auch Index genannt, ist ein einzigartiges Feature von Git, das es in keinem anderen DVCS gibt, zumindest nicht im gleichen Sinne. Als Staging wird der Prozess der Auswahl von Dateien für den nächsten eigenen Commit bezeichnet. Dadurch ist es möglich zu entscheiden, welche Dateien als nächstes an den Server übergeben werden. Das ist praktisch, wenn nicht alle geänderten Dateien auf einmal hochgeladen werden sollen. Dieses Feature erhöht jedoch die Komplexität von Git, weshalb nicht jeder die Funktion gut findet.

In Mercurial gibt es keinen solchen Index oder Staging-Bereich vor dem Commit. Veränderungen werden so hochgeladen, wie sie im Arbeitsverzeichnis vorhanden sind. Für viele wird das eine adäquate und einfache Lösung darstellen. Wenn man aber doch eine Auswahl der Teile des Arbeitsverzeichnisses treffen möchte, die übergeben werden sollen, stehen die Mercurial Extensions DirState und Mercurial Queues zur Verfügung.

Unterstütze Betriebssysteme

Häufig wird auch die unterschiedliche Unterstützung von Betriebssystemen in der Debatte um Git und Mercurial erwähnt. Ursprünglich kommen sowohl Git als auch Mercurial aus der Linux-Welt, weil sie beide als Versionskontrollsysteme für das Linux-Kernel-Projekt entworfen wurden. Dieser Kampf wurde von Git gewonnen; Git ist bis heute sehr auf Linux fokussiert. So hat Git beispielsweise viel mehr GUIs für Linux als Mercurial. Mercurial ist hingegen leicht auf Windows aufsetzbar.

Git kann mit Msygit auch unter Windows benutzt werden. Allerdings können das Setup und die Verwendung von Git auf Windows etwas komplizierter werden, vor allem wenn die Authentifizierung per SSH-Key erfolgen soll, nicht mit einem Passwort. Insofern sollte man die eigenen Präferenzen in Sachen Betriebssystem in die Auswahl des verteilten Versionskontrollsystems mit einfließen lassen.

Git vs Mercurial – was wählen Sie?

Dieser Leitfaden hat versucht, Git und Mercurial auf einem hohen Level zu vergleichen, also die markantesten Unterschiede aufzuzeigen. Grundsätzlich sind sich Git und Mercurial sehr ähnlich und tolle Versionskontrollsysteme. Sie unterscheiden sich jedoch in ihrem Design und benötigen unterschiedlich viel Fachkenntnis seitens des Teams.

Git mag komplexer und schwerer zu erlernen sein; auch die Dokumentation ist eher unscharf. Auf der Habenseite kann es jedoch verbuchen, dass es vielseitiger ist, wenn man erst einmal gelernt hat damit umzugehen. Nicht umsonst stellt Git den Branchen-Standard dar. Es ist leichter, Entwickler zu finden die bereits mit Git vertraut sind, als solche, die sich mit Mercurial auskennen. Bei Mercurial kann der Einstieg allerdings einfacher sein; auch langfristig wird es Entwicklern unter Umständen nicht so viel Kopfzerbrechen bereiten wie Git. Hier ist es jedoch das Branching-Modell, das schwerer zu verstehen ist. Außerdem gibt es keine Staging-Area.

Dieser Artikel erschien zuerst auf https://deveo.com/git-vs-mercurial/.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -