Ich benutze git seit einiger Zeit unter Windows (mit msysGit) und ich mag die Idee der verteilten Quellcodeverwaltung. Erst kürzlich habe ich mir Mercurial (hg) angesehen und es sieht interessant aus. Ich kann mich jedoch nicht um die Unterschiede zwischen hg und git kümmern.
Hat jemand einen Nebeneinander-Vergleich zwischen git und hg gemacht? Ich bin interessiert zu wissen, was sich von hg und git unterscheidet, ohne in eine Fanboy-Diskussion einsteigen zu müssen.
Antworten:
Diese Artikel können helfen:
Edit : Der Vergleich von Git und Mercurial mit Prominenten scheint ein Trend zu sein. Hier ist noch eine:
Ich arbeite an Mercurial, aber grundsätzlich glaube ich, dass beide Systeme gleichwertig sind. Beide arbeiten mit denselben Abstraktionen: einer Reihe von Schnappschüssen (Änderungssätzen), aus denen sich die Geschichte zusammensetzt. Jeder Änderungssatz weiß, woher er stammt (der übergeordnete Änderungssatz) und kann viele untergeordnete Änderungssätze haben. Die aktuelle hg-git- Erweiterung bietet eine Zwei-Wege-Brücke zwischen Mercurial und Git und zeigt diesen Punkt.
Git konzentriert sich stark auf die Mutation dieses Verlaufsgraphen (mit allen damit verbundenen Konsequenzen), während Mercurial das Umschreiben des Verlaufs nicht fördert, aber es ist trotzdem einfach und die Konsequenzen sind genau das, was Sie erwarten sollten (das heißt Wenn ich ein bereits vorhandenes Änderungsset ändere, wird es von Ihrem Kunden als neu angesehen, wenn Sie es von mir abrufen. Mercurial tendiert also zu zerstörungsfreien Befehlen.
Was leichte Zweige betrifft, so hat Mercurial seit ... Repositories mit mehreren Zweigen unterstützt , denke ich immer. Git-Repositorys mit mehreren Zweigen sind genau das: mehrere unterschiedliche Entwicklungsstränge in einem einzigen Repository. Git fügt diesen Strängen dann Namen hinzu und ermöglicht es Ihnen, diese Namen remote abzufragen. Die Lesezeichen- Erweiterung für Mercurial fügt lokale Namen hinzu. Mit Mercurial 1.6 können Sie diese Lesezeichen beim Drücken / Ziehen verschieben.
Ich benutze Linux, aber anscheinend ist TortoiseHg schneller und besser als das Git-Äquivalent unter Windows (aufgrund der besseren Nutzung des schlechten Windows-Dateisystems). Sowohl http://github.com als auch http://bitbucket.org bieten Online-Hosting an. Der Service bei Bitbucket ist großartig und reaktionsschnell (ich habe Github noch nicht ausprobiert).
Ich habe mich für Mercurial entschieden, da es sich sauber und elegant anfühlt. Die Shell / Perl / Ruby-Skripte, die ich mit Git erhalten habe, haben mich abgeschreckt. Werfen Sie einen Blick auf die git-instaweb.shDatei, wenn Sie wissen möchten, was ich meine: Es ist ein Shell- Skript, das ein Ruby- Skript generiert , von dem ich glaube, dass es einen Webserver ausführt. Das Shell-Skript generiert ein weiteres Shell-Skript, um das erste Ruby-Skript zu starten. Es gibt auch ein bisschen Perl .
Ich mag den Blog-Beitrag , der Mercurial und Git mit James Bond und MacGyver vergleicht - Mercurial ist irgendwie zurückhaltender als Git. Es scheint mir, dass Menschen, die Mercurial verwenden, nicht so leicht beeindruckt sind. Dies spiegelt sich darin wider, wie jedes System das tut, was Linus als "die coolste Zusammenführung aller Zeiten" bezeichnet hat. . In Git können Sie mit einem nicht verwandten Repository zusammenführen, indem Sie Folgendes tun:
git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit
Diese Befehle sehen für mich ziemlich arkan aus. In Mercurial machen wir:
hg pull --force <project-to-union-merge>
hg merge
hg commit
Beachten Sie, dass die Mercurial-Befehle einfach und überhaupt nicht speziell sind. Das einzig Ungewöhnliche ist das --forceFlag to hg pull, das benötigt wird, da Mercurial ansonsten abbricht, wenn Sie aus einem nicht verwandten Repository ziehen. Es sind solche Unterschiede, die Mercurial für mich eleganter erscheinen lassen.
git pull <url-of-project>. Die Mail, die Sie zitiert haben, stammt aus den frühen Tagen von Git (2005)
Git ist eine Plattform, Mercurial ist "nur" eine Anwendung. Git ist eine versionierte Dateisystemplattform, die zufällig mit einer DVCS-App im Lieferumfang enthalten ist. Wie bei Plattform-Apps üblich, ist sie jedoch komplexer und weist gröbere Kanten auf als fokussierte Apps. Dies bedeutet aber auch, dass das VCS von git immens flexibel ist und dass es eine große Tiefe von Dingen gibt, die Sie nicht mit Quellcodeverwaltung machen können.
Das ist die Essenz des Unterschieds.
Git wird am besten von Grund auf verstanden - vom Repository-Format an. Scott Chacons Git Talk ist eine hervorragende Grundlage dafür. Wenn Sie versuchen, Git zu verwenden, ohne zu wissen, was unter der Haube passiert, werden Sie irgendwann verwirrt sein (es sei denn, Sie halten sich nur an sehr grundlegende Funktionen). Dies kann dumm klingen , wenn alles , was Sie wollen ein DVCS für Ihre tägliche Programmierroutine ist, aber das Genie git ist , dass das Repository - Format ist eigentlich sehr einfach und man kann ganz einfach git den gesamten Betrieb verstehen.
Für einige technischere Vergleiche sind die besten Artikel, die ich persönlich gesehen habe, Dustin Sallings ':
Er hat beide DVCSs tatsächlich ausgiebig benutzt und versteht sie beide gut - und zog am Ende Git vor.
Der große Unterschied liegt bei Windows. Mercurial wird nativ unterstützt, Git nicht. Mit bitbucket.org können Sie ein sehr ähnliches Hosting wie github.com erhalten (sogar noch besser, wenn Sie ein kostenloses privates Repository erhalten). Ich habe msysGit eine Weile benutzt, bin aber zu Mercurial gewechselt und war sehr zufrieden damit.
Wenn Sie ein Windows-Entwickler sind, der nach einer grundlegenden, nicht verbundenen Revisionskontrolle sucht, wählen Sie Hg. Ich fand Git unverständlich, während Hg einfach und gut in die Windows-Shell integriert war. Ich lud Hg herunter und folgte diesem Tutorial (hginit.com) - zehn Minuten später hatte ich ein lokales Repo und arbeitete wieder an meinem Projekt.
Ich denke, die beste Beschreibung zu "Mercurial vs. Git" ist:
Sie sind fast identisch. Der wichtigste Unterschied aus meiner Sicht (ich meine, der Grund, warum ich mich für ein DVCS entschieden habe) ist, wie die beiden Programme Zweige verwalten.
Um einen neuen Zweig mit Mercurial zu starten, klonen Sie einfach das Repository in ein anderes Verzeichnis und beginnen mit der Entwicklung. Dann ziehen Sie und verschmelzen. Mit git müssen Sie dem neuen Themenzweig, den Sie verwenden möchten, explizit einen Namen geben, und dann beginnen Sie mit der Codierung im selben Verzeichnis .
Kurz gesagt, jeder Zweig in Mercurial benötigt ein eigenes Verzeichnis. In Git arbeiten Sie normalerweise in einem einzelnen Verzeichnis. Das Wechseln von Zweigen in Mercurial bedeutet das Ändern von Verzeichnissen. In Git bedeutet dies, Git zu bitten, den Inhalt des Verzeichnisses mit Git Checkout zu ändern.
Ich bin ehrlich: Ich weiß nicht, ob es mit Mercurial möglich ist, dasselbe zu tun, aber da ich normalerweise an Webprojekten arbeite, erscheint es mir sehr bequem, immer dasselbe Verzeichnis mit git zu verwenden, da ich es nicht erneut tun muss -Konfigurieren Sie Apache und starten Sie es neu. Ich verwirre mein Dateisystem nicht jedes Mal, wenn ich verzweige.
Bearbeiten: Wie Deestan feststellte, hat Hg Zweige benannt , die in einem einzigen Repository gespeichert werden können und es dem Entwickler ermöglichen, Zweige innerhalb derselben Arbeitskopie zu wechseln. Git-Zweige sind sowieso nicht genau die gleichen wie Mercurial-Zweige: Sie sind permanent und werfen keine Zweige weg, wie in Git. Das heißt, wenn Sie einen benannten Zweig für experimentelle Aufgaben verwenden, auch wenn Sie ihn niemals zusammenführen möchten, wird er im Repository gespeichert. Aus diesem Grund empfiehlt Hg, Klone für experimentelle Aufgaben mit kurzer Laufzeit und benannte Zweige für Aufgaben mit langer Laufzeit zu verwenden, z. B. für Release-Zweige.
Der Grund, warum viele Hg-Benutzer Klone gegenüber benannten Zweigen bevorzugen, ist viel sozialer oder kultureller als technischer Natur. Mit den letzten Versionen von Hg ist es beispielsweise sogar möglich, einen benannten Zweig zu schließen und Metadaten rekursiv aus Änderungssätzen zu entfernen.
Auf der anderen Seite lädt git ein, "benannte Zweige" zu verwenden, die nicht permanent sind und nicht als Metadaten in jedem Änderungssatz gespeichert werden.
Aus meiner persönlichen Sicht ist das Modell von git eng mit dem Konzept der benannten Zweige verbunden und wechselt zwischen einem Zweig und einem anderen mit demselben Verzeichnis. hg kann dasselbe mit benannten Zweigen tun, aber es fördert die Verwendung von Klonen, die ich persönlich nicht besonders mag.
Es gibt einen großen Unterschied zwischen Git und Quecksilber ; die Art und Weise, wie sie jedes Commit darstellen. git stellt Commits als Schnappschüsse dar, während mercurial sie als Unterschiede darstellt.
Was bedeutet das in der Praxis? Nun, viele Operationen sind in Git schneller, z. B. das Wechseln zu einem anderen Commit, das Vergleichen von Commits usw. Insbesondere, wenn diese Commits weit entfernt sind.
AFAIK Es gibt keinen Vorteil von Mercurials Ansatz.
Nichts. Beide machen das Gleiche, beide arbeiten ungefähr gleich. Der einzige Grund, warum Sie einen über den anderen wählen sollten, ist, wenn Sie bei einem Projekt helfen, das bereits eines verwendet.
Der andere mögliche Grund für die Auswahl ist eine Anwendung oder ein Dienst, der nur eines der Systeme unterstützt. Zum Beispiel habe ich mich wegen Github für Git entschieden .
Auch Googles Vergleich (obwohl es ein bisschen alt ist, 2008 gemacht)
Wenn ich sie richtig verstehe (und ich bin kein Experte für jeden), haben sie grundsätzlich eine andere Philosophie. Ich habe Mercurial zum ersten Mal seit 9 Monaten verwendet. Jetzt habe ich Git für 6 verwendet.
hg ist eine Versionskontrollsoftware. Das Hauptziel besteht darin, Versionen einer Software zu verfolgen.
git ist ein zeitbasiertes Dateisystem. Ziel ist es, einem Dateisystem eine weitere Dimension hinzuzufügen. Die meisten haben Dateien und Ordner, Git fügt Zeit hinzu. Dass es als VCS fantastisch funktioniert, ist ein Nebenprodukt seines Designs.
In hg gibt es eine Geschichte des gesamten Projekts, das immer gepflegt werden soll. Standardmäßig möchte hg alle Änderungen an allen Objekten durch alle Benutzer beim Drücken und Ziehen.
In git gibt es nur einen Pool von Objekten und diese Verfolgungsdateien (Zweige / Köpfe), die bestimmen, welche Gruppe dieser Objekte den Baum von Dateien in einem bestimmten Zustand darstellt. Beim Drücken oder Ziehen sendet git nur die Objekte, die für die bestimmten Zweige benötigt werden, die Sie drücken oder ziehen. Dies ist eine kleine Teilmenge aller Objekte.
Für Git gibt es kein "1 Projekt". Du könntest 50 Projekte im selben Repo haben und Git wäre das egal. Jeder kann separat im selben Repo verwaltet werden und gut leben.
Hgs Konzept von Zweigen ist Verzweigungen vom Hauptprojekt oder Verzweigungen von Zweigen usw. Git hat kein solches Konzept. Ein Zweig in Git ist nur ein Zustand des Baumes, alles ist ein Zweig in Git. Welcher Zweig offiziell, aktuell oder neu ist, hat in git keine Bedeutung.
Ich weiß nicht, ob das Sinn machte. Wenn ich Bilder zeichnen könnte, könnte hg so aussehen, wo jedes Commit ein isto
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
Ein Baum mit einer einzigen Wurzel und Ästen. Während Git das kann und die Leute es oft so benutzen, wird es nicht durchgesetzt. Ein Git-Bild könnte, wenn es so etwas gibt, leicht so aussehen
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
In gewisser Weise macht es nicht einmal Sinn, Zweige in Git zu zeigen.
Eine Sache, die für die Diskussion sehr verwirrend ist: Git und Mercurial haben beide einen sogenannten "Zweig", aber sie sind nicht im entferntesten dieselben Dinge. Ein Zweig in Quecksilber entsteht, wenn es Konflikte zwischen verschiedenen Repos gibt. Ein Zweig in Git ähnelt anscheinend einem Klon in HG. Aber ein Klon ist zwar nicht ähnlich, aber definitiv nicht dasselbe. Betrachten Sie mich als Versuch in git vs hg mit dem Chrom-Repo, das ziemlich groß ist.
$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'
real 0m1.759s
user 0m1.596s
sys 0m0.144s
Und jetzt in hg mit Klon
$ time hg clone project/ some-clone/
updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real 0m58.196s
user 0m19.901s
sys 0m8.957
Beides sind heiße Läufe. Das heißt, ich habe sie zweimal ausgeführt und dies ist der zweite Lauf. hg clone ist eigentlich das gleiche wie git-new-workdir. Beide machen ein völlig neues Arbeitsverzeichnis, fast so, als hätten Sie getippt cp -r project project-clone. Das ist nicht dasselbe wie einen neuen Zweig in Git zu machen. Es ist viel schwerer. Wenn es ein echtes Äquivalent zur Verzweigung von git in hg gibt, weiß ich nicht, was es ist.
Ich verstehe auf einer bestimmten Ebene, dass hg und git in der Lage sein könnten, ähnliche Dinge zu tun. Wenn ja, dann gibt es immer noch einen großen Unterschied im Workflow, zu dem sie Sie führen. In git besteht der typische Workflow darin, für jedes Feature einen Zweig zu erstellen.
git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support
Das hat gerade 3 Zweige erstellt, jeder basiert auf einem Zweig namens Master. (Ich bin mir sicher, dass es in git eine Möglichkeit gibt, diese 1 Zeile anstelle von 2 zu machen.)
Nun, um an einem zu arbeiten, mache ich es einfach
git checkout fix-game-save-bug
und anfangen zu arbeiten. Festschreiben von Dingen usw. Das Wechseln zwischen Zweigen selbst in einem Projekt, das so groß wie Chrom ist, erfolgt fast augenblicklich. Ich weiß eigentlich nicht, wie ich das in hg machen soll. Es ist nicht Teil von Tutorials, die ich gelesen habe.
Ein weiterer großer Unterschied. Gits Bühne.
Git hat diese Idee einer Bühne. Sie können sich das als versteckten Ordner vorstellen. Wenn Sie ein Commit durchführen, legen Sie nur fest, was sich auf der Bühne befindet, nicht die Änderungen in Ihrem Arbeitsbaum. Das mag seltsam klingen. Wenn Sie alle Änderungen in Ihrem Arbeitsbaum festschreiben möchten, werden alle git commit -ageänderten Dateien zur Bühne hinzugefügt und anschließend festgeschrieben.
Was ist der Sinn der Bühne dann? Sie können Ihre Commits einfach trennen. Stellen Sie sich vor, Sie haben joypad.cpp und gamesave.cpp bearbeitet und möchten diese separat festschreiben
git add joypad.cpp // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp // copies to stage
git commit -m "fixed game save bug"
Git hat sogar Befehle, um zu entscheiden, welche bestimmten Zeilen in derselben Datei Sie auf die Bühne kopieren möchten, damit Sie diese Commits auch separat aufteilen können. Warum willst du das tun? Weil andere als separate Commits nur diejenigen abrufen können, die sie möchten, oder wenn es ein Problem gab, können sie nur das Commit zurücksetzen, bei dem das Problem aufgetreten ist.
git add --patchsiehe linux.die.net/man/1/git-add oder verwenden Sie git add -i, wie in stackoverflow.com/questions/2372583/…
checkout -b <name>, könnten Sie einfach git branch <name>einen neuen Zweig erstellen, ohne zu ihm zu
Im versioncontrolblog finden Sie eine dynamische Vergleichstabelle, in der Sie verschiedene Versionskontrollsysteme vergleichen können.
dir-a/foo.czu dir-b/foo.cund halten arbeiten dir-b/foo.c, dann auf Ihre Arbeit dir-a/foo.ckorrekt fusionierte nach einem Zug mit meiner Arbeit sein wird.
Bei der Arbeit mit Filialen (insbesondere kurzfristigen) gibt es erhebliche Unterschiede.
Es wird in diesem Artikel (BranchingExplained) erklärt, der Mercurial mit Git vergleicht.
Gibt es Windows-basierte Mitarbeiter in Ihrem Projekt?
Denn wenn ja, scheint die Git-for-Windows-Benutzeroberfläche umständlich, schwierig und unfreundlich zu sein.
Im Gegensatz dazu ist Mercurial-on-Windows ein Kinderspiel.
Eine Sache, die zwischen mercurial von bitbucket.org und git von github zu beachten ist, ist, dass mercurial so viele private Repositories haben kann, wie Sie möchten, aber github müssen Sie auf ein kostenpflichtiges Konto upgraden. Deshalb greife ich zu Bitbucket, das Quecksilber verwendet.
Irgendwann im letzten Jahr habe ich sowohl git als auch hg für meinen eigenen Gebrauch evaluiert und mich für hg entschieden. Ich fand, es sah nach einer saubereren Lösung aus und funktionierte zu dieser Zeit besser auf mehr Plattformen. Es war jedoch meistens ein Fehler.
In jüngerer Zeit habe ich angefangen, git zu verwenden, weil git-svn und die Fähigkeit, als Subversion-Client zu fungieren. Das hat mich überzeugt und ich bin jetzt komplett auf Git umgestiegen. Ich denke, es hat eine etwas höhere Lernkurve (besonders wenn Sie sich um die Innenseiten kümmern müssen), aber es ist wirklich ein großartiges System. Ich werde diese beiden Vergleichsartikel lesen, die John jetzt gepostet hat.
Ich bin gerade dabei, von SVN auf ein DVCS zu migrieren (während ich über meine Ergebnisse blogge, meine ersten wirklichen Blogging-Bemühungen ...), und ich habe ein bisschen recherchiert (= googeln). Soweit ich sehen kann, können Sie die meisten Dinge mit beiden Paketen erledigen. Es scheint, als hätte Git ein paar mehr oder besser implementierte erweiterte Funktionen. Ich bin der Meinung, dass die Integration mit Windows für Mercurial mit TortoiseHg etwas besser ist. Ich weiß, dass es auch Git Cheetah gibt (ich habe beide ausprobiert), aber die Quecksilberlösung fühlt sich einfach robuster an.
Angesichts der Tatsache, dass beide Open Source sind (richtig?), Denke ich auch nicht, dass wichtige Funktionen fehlen werden. Wenn etwas wichtig ist, werden die Leute danach fragen, die Leute werden es codieren.
Ich denke, dass Git und Mercurial für gängige Praktiken mehr als ausreichend sind. Beide haben große Projekte, die sie verwenden (Git -> Linux-Kernel, Mercurial -> Mozilla-Foundation-Projekte, beide natürlich unter anderem), daher denke ich, dass beiden auch nicht wirklich etwas fehlt.
Davon abgesehen interessiert mich, was andere Leute dazu sagen, da dies eine großartige Quelle für meine Blogging-Bemühungen wäre ;-)
Im InfoQ-Handbuch zu DVCS finden Sie eine großartige und umfassende Vergleichstabelle und -tabelle zu git, Mercurial und Bazaar .
Mir ist klar, dass dies kein Teil der Antwort ist, aber in diesem Sinne denke ich auch, dass die Verfügbarkeit stabiler Plugins für Plattformen wie NetBeans und Eclipse eine Rolle spielt, welches Tool besser für die Aufgabe geeignet ist oder vielmehr welches Tool passt am besten zu "dir". Das heißt, es sei denn, Sie möchten es wirklich auf CLI-Weise tun.
Sowohl Eclipse (und alles, was darauf basiert) als auch NetBeans haben manchmal Probleme mit Remote-Dateisystemen (wie SSH) und externen Aktualisierungen von Dateien. Dies ist ein weiterer Grund, warum Sie möchten, dass alles, was Sie wählen, "nahtlos" funktioniert.
Ich versuche gerade, diese Frage auch für mich selbst zu beantworten. Und ich habe die Kandidaten auf Git oder Mercurial reduziert. Ich danke Ihnen allen, dass Sie nützliche Beiträge zu diesem Thema geliefert haben, ohne religiös zu werden.
Noch ein interessanter Vergleich von Mercurial und Git: Mercurial vs Git . Das Hauptaugenmerk liegt auf Interna und deren Einfluss auf den Verzweigungsprozess.
Wenn Sie an einem Leistungsvergleich von Mercurial und Git interessiert sind, lesen Sie diesen Artikel . Die Schlussfolgerung lautet:
Git und Mercurial drehen sich beide in guten Zahlen, machen aber einen interessanten Kompromiss zwischen Geschwindigkeit und Repository-Größe. Mercurial ist sowohl mit Hinzufügungen als auch mit Änderungen schnell und hält gleichzeitig das Repository-Wachstum unter Kontrolle. Git ist auch schnell, aber sein Repository wächst sehr schnell mit geänderten Dateien, bis Sie neu packen - und diese Umpackungen können sehr langsam sein. Das gepackte Repository ist jedoch viel kleiner als das von Mercurial.
Auf der Mercurial-Website werden die Ähnlichkeiten und Unterschiede zwischen den beiden Systemen ausführlich beschrieben und die Unterschiede zwischen dem Wortschatz und den zugrunde liegenden Konzepten erläutert. Als langjähriger Git-Benutzer hat es mir wirklich geholfen, die Mercurial-Denkweise zu verstehen.
Wenn Sie von SVN migrieren, verwenden Sie Mercurial, da die Syntax für SVN-Benutzer VIEL verständlicher ist. Davon abgesehen kann man auch nichts falsch machen. Überprüfen Sie jedoch das GIT-Tutorial und HGinit, bevor Sie eines davon auswählen.
Dieser Link kann Ihnen helfen, den Unterschied zu verstehen. Http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
Einige Leute denken, dass VCS-Systeme kompliziert sein müssen. Sie fördern die Erfindung von Begriffen und Konzepten auf dem Feld. Sie würden wahrscheinlich denken, dass zahlreiche Doktorarbeiten zu diesem Thema interessant wären. Unter diesen sind wahrscheinlich diejenigen, die Git entworfen haben.
Mercurial ist mit einer anderen Mentalität gestaltet. Entwickler sollten sich nicht viel für VCS interessieren und stattdessen ihre Zeit mit ihrer Hauptfunktion verbringen: dem Software-Engineering. Mit Mercurial können Benutzer das System verwenden und gerne missbrauchen, ohne dass sie nicht behebbare Fehler machen können.
Jedes professionelle Tool muss über eine klar gestaltete und intuitive CLI verfügen. Mercurial-Benutzer können den größten Teil der Arbeit erledigen, indem sie einfache Befehle ohne seltsame Optionen ausgeben. In Git Double Dash sind verrückte Optionen die Norm. Mercurial hat einen erheblichen Vorteil, wenn Sie eine CLI-Person sind (und um ehrlich zu sein, sollte dies jeder Software-Ingenieur mit Selbstachtung tun).
Angenommen, Sie führen versehentlich ein Commit durch. Sie haben vergessen, einige Dateien zu bearbeiten. Um Ihre Aktion in Mercurial rückgängig zu machen, geben Sie einfach Folgendes ein:
$ hg rollback
Sie erhalten dann eine Nachricht, dass das System Ihre letzte Transaktion rückgängig macht.
In Git müssen Sie Folgendes eingeben:
$ git reset --soft HEAD^
Angenommen, Sie haben eine Idee, worum es beim Zurücksetzen geht. Aber zusätzlich müssen Sie wissen, was "--soft" und "--hard" Resets sind (irgendwelche intuitiven Vermutungen?). Oh und natürlich vergiss am Ende nicht den '^' Charakter! (Was in Ritchies Namen ist das ...)
Die Integration von Mercurial in Tools von Drittanbietern wie kdiff3 und meld ist ebenfalls viel besser. Generieren Sie Ihre Patches und führen Sie Ihre Zweige ohne großen Aufwand zusammen. Mercurial enthält auch einen einfachen http-Server, den Sie durch Eingabe aktivieren
hg serve
Und lassen Sie andere Ihr Repository durchsuchen.
Unter dem Strich macht Git das, was Mercurial macht, viel komplizierter und mit einer weitaus schlechteren CLI. Verwenden Sie Git, wenn Sie das VCS Ihres Projekts in ein wissenschaftliches Forschungsfeld verwandeln möchten. Verwenden Sie Mercurial, wenn Sie die VCS-Arbeit erledigen möchten, ohne sich darum zu kümmern, und sich auf Ihre eigentlichen Aufgaben konzentrieren möchten.