Was ist der Unterschied zwischen Mercurial und Git?

StackOverflow https://stackoverflow.com/questions/35837

Frage

Ich verwende Git nun schon seit einiger Zeit unter Windows (mit msysGit) und mir gefällt die Idee der verteilten Quellcodeverwaltung.Erst kürzlich habe ich mir Mercurial (hg) angesehen und es sieht interessant aus.Allerdings kann ich mir die Unterschiede zwischen hg und git nicht vorstellen.

Hat jemand einen direkten Vergleich zwischen git und hg durchgeführt?Ich bin daran interessiert zu wissen, was hg und git unterscheidet, ohne mich in eine Fanboy-Diskussion stürzen zu müssen.

War es hilfreich?

Lösung

Diese Artikel könnten hilfreich sein:

Bearbeiten:Der Vergleich von Git und Mercurial mit Prominenten scheint im Trend zu liegen.Hier ist noch einer:

Andere Tipps

Ich arbeite an Mercurial, bin aber grundsätzlich davon überzeugt, dass beide Systeme gleichwertig sind.Beide arbeiten mit den gleichen Abstraktionen:eine Reihe von Snapshots (Changesets), aus denen der Verlauf besteht.Jeder Änderungssatz weiß, woher er stammt (der übergeordnete Änderungssatz) und kann viele untergeordnete Änderungssätze haben.Das Kürzliche hg-git Die Erweiterung bietet eine bidirektionale Brücke zwischen Mercurial und Git und zeigt diesen Punkt gewissermaßen.

Git konzentriert sich stark auf die Mutation dieses Verlaufsdiagramms (mit allen Konsequenzen, die das mit sich bringt), während Mercurial das Umschreiben der Geschichte nicht fördert. aber es ist trotzdem einfach zu machen und die daraus resultierenden Konsequenzen sind genau das, was Sie erwarten sollten (das heißt, wenn ich einen Änderungssatz ändere, den Sie bereits haben, wird Ihr Client ihn als neu ansehen, wenn Sie ihn von mir übernehmen).Mercurial hat also eine Voreingenommenheit hin zu zerstörungsfreien Befehlen.

Was leichtgewichtige Zweige betrifft, so hat Mercurial Repositorys mit unterstützt mehrere Filialen seit..., denke ich immer.Git-Repositorys mit mehreren Branches 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 aus der Ferne abzufragen.Der Lesezeichen Die Erweiterung für Mercurial fügt lokale Namen hinzu, und mit Mercurial 1.6 können Sie diese Lesezeichen durch Drücken/Ziehen verschieben.

Ich verwende Linux, aber anscheinend ist TortoiseHg schneller und besser als das Git-Äquivalent unter Windows (aufgrund der besseren Nutzung des schlechten Windows-Dateisystems).Beide http://github.com Und http://bitbucket.org Ich biete 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, weil es sich sauber und elegant anfühlt – die Shell-/Perl-/Ruby-Skripte, die ich mit Git bekam, haben mich abgeschreckt.Versuchen Sie, einen Blick darauf zu werfen git-instaweb.sh Datei Wenn du wissen willst, was ich meine:es ist ein Hülse Skript, das eine generiert Rubin Skript, das meiner Meinung nach 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, zur Sicherheit.

Ich mag Blogeintrag das vergleicht Mercurial und Git mit James Bond und MacGyver – Mercurial ist irgendwie zurückhaltender als Git.Es scheint mir, dass Menschen, die Mercurial verwenden, nicht so leicht zu beeindrucken sind.Dies spiegelt sich darin wider, wie jedes System das tut, was Linus beschrieben hat „Die coolste Fusion aller Zeiten!“.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 geheimnisvoll aus.Bei Mercurial machen wir:

hg pull --force <project-to-union-merge>
hg merge
hg commit

Beachten Sie, dass die Mercurial-Befehle schlicht und überhaupt nicht besonders sind – das einzig Ungewöhnliche ist das --force Flagge zu hg pull, was erforderlich ist, da Mercurial andernfalls abbricht, wenn Sie aus einem nicht verwandten Repository ziehen.Es sind solche Unterschiede, die Mercurial für mich eleganter erscheinen lassen.

Git ist eine Plattform, Mercurial ist „nur“ eine Anwendung.Git ist eine versionierte Dateisystemplattform, die zufällig mit einer DVCS-App ausgeliefert wird, aber wie bei Plattform-Apps üblich, ist sie komplexer und weist rauere Kanten auf als fokussierte Apps.Dies bedeutet aber auch, dass das VCS von Git äußerst flexibel ist und dass Sie mit Git eine große Bandbreite an Dingen tun können, die nicht der Quellcodeverwaltung unterliegen.

Das ist der Kern des Unterschieds.

Git versteht man am besten von Grund auf – vom Repository-Format aufwärts. Scott Chacons Git Talk ist dafür eine hervorragende Grundierung.Wenn Sie versuchen, Git zu verwenden, ohne zu wissen, was unter der Haube passiert, werden Sie irgendwann verwirrt sein (es sei denn, Sie beschränken sich nur auf sehr grundlegende Funktionen).Das hört sich vielleicht dumm an, wenn Sie doch nur ein DVCS für Ihre tägliche Programmierroutine haben wollen, aber das Geniale an Git ist, dass das Repository-Format eigentlich sehr einfach ist und Sie dürfen Verstehen Sie ganz einfach die gesamte Funktionsweise von Git.

Für einige eher technisch orientierte Vergleiche: Die besten Artikel, die ich persönlich gesehen habe, sind die von Dustin Sallings:

Er hat tatsächlich beide DVCSs ausgiebig genutzt und versteht sie beide gut – und hat sich schließlich für Git entschieden.

Der große Unterschied besteht unter Windows.Mercurial wird nativ unterstützt, Git nicht.Sie können ein sehr ähnliches Hosting erhalten github.com mit bitbucket.org (eigentlich sogar noch besser, da Sie ein kostenloses privates Repository erhalten).Ich habe msysGit eine Zeit lang verwendet, bin dann aber zu Mercurial gewechselt und war sehr zufrieden damit.

Wenn Sie als Windows-Entwickler nach einer einfachen, unabhängigen Revisionskontrolle suchen, entscheiden Sie sich für Hg.Ich fand Git unverständlich, während Hg einfach und gut in die Windows-Shell integriert war.Ich habe Hg heruntergeladen und bin gefolgt dieses Tutorial (hginit.com) - Zehn Minuten später hatte ich ein lokales Repo und konnte wieder an meinem Projekt arbeiten.

Ich denke, die beste Beschreibung zu „Mercurial vs.Git" ist:

„Git ist Wesley Snipes.„Mercurial ist Denzel Washington“

Sie sind nahezu identisch.Der aus meiner Sicht wichtigste Unterschied (ich meine, der Grund, warum ich mich für ein DVCS entschieden habe) besteht darin, wie die beiden Programme Zweige verwalten.

Um mit Mercurial einen neuen Zweig zu starten, klonen Sie einfach das Repository in ein anderes Verzeichnis und mit der Entwicklung beginnen.Dann ziehen Sie und verschmelzen.Bei Git müssen Sie dem neuen Themenzweig, den Sie verwenden möchten, explizit einen Namen geben und dann mit dem Codieren beginnen das gleiche Verzeichnis verwenden.

Kurz gesagt, jede Filiale in Mercurial benötigt ihr eigenes Verzeichnis;In Git arbeiten Sie normalerweise in einem einzelnen Verzeichnis.Der Wechsel der Filiale in Mercurial bedeutet einen Verzeichniswechsel;In Git bedeutet das, 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 Apache nicht neu konfigurieren und neu starten muss es und ich bringe mein Dateisystem nicht jedes Mal durcheinander, wenn ich verzweige.

Bearbeiten:Wie Deestan bemerkte, hat Hg benannte Zweige, die in einem einzigen Repository gespeichert werden kann und es dem Entwickler ermöglicht, Zweige innerhalb derselben Arbeitskopie zu wechseln.Git-Branches sind ohnehin nicht genau die gleichen wie Mercurial-benannte Branches:Sie sind dauerhaft und werfen keine Äste weg, wie bei Git.Das heißt, wenn Sie einen benannten Zweig für experimentelle Aufgaben verwenden, wird er im Repository gespeichert, auch wenn Sie sich entscheiden, ihn nie zusammenzuführen.Aus diesem Grund empfiehlt Hg die Verwendung von Klonen für experimentelle Aufgaben mit kurzer Laufzeit und benannte Branches für Aufgaben mit langer Laufzeit, beispielsweise für Release-Branches.

Der Grund, warum viele Hg-Benutzer Klone gegenüber benannten Zweigen bevorzugen, ist eher 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 dazu ein, „benannte Zweige“ zu verwenden, die nicht dauerhaft sind und nicht als Metadaten in jedem Änderungssatz gespeichert werden.

Aus meiner persönlichen Sicht ist das Git-Modell also eng mit dem Konzept der benannten Zweige und dem Wechsel zwischen einem Zweig und einem anderen innerhalb desselben Verzeichnisses verknüpft;hg kann dasselbe mit benannten Zweigen tun, fördert aber dennoch die Verwendung von Klonen, was mir persönlich nicht so gut gefällt.

Es gibt einen riesig Unterschied zwischen Idiot Und Quecksilber;die Art und Weise, wie sie jedes Commit darstellen. Idiot stellt Commits als Snapshots dar, while Quecksilber stellt sie als Diffs dar.

Was bedeutet das in der Praxis?Nun, viele Vorgänge sind in Git schneller, z. B. das Wechseln zu einem anderen Commit, das Vergleichen von Commits usw.Vor allem, wenn diese Commits weit entfernt sind.

AFAIK, der Ansatz von Mercurial bietet keinen Vorteil.

Nichts.Beide machen das Gleiche, beide leisten ungefähr die gleiche Leistung.Der einzige Grund, warum Sie sich für eines entscheiden sollten, ist, wenn Sie bei einem Projekt mithelfen, das bereits eines verwendet.

Der andere mögliche Grund für die Wahl eines solchen Systems ist eine Anwendung oder ein Dienst, der nur eines der Systeme unterstützt.Ich habe mich zum Beispiel so ziemlich dafür entschieden, Git zu lernen, weil Github..

Auch der Vergleich von Google (obwohl er etwas alt ist, erstellt im Jahr 2008)

http://code.google.com/p/support/wiki/DVCSAnalysis

Wenn ich sie richtig verstehe (und ich bin alles andere als ein Experte für jedes einzelne), haben sie im Grunde genommen jeweils eine andere Philosophie.Ich habe Mercurial zum ersten Mal 9 Monate lang 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 großartig funktioniert, ist ein Nebenprodukt seines Designs.

In hg gibt es eine Historie des gesamten Projekts, die stets gepflegt werden soll.Ich glaube, hg möchte standardmäßig, dass alle Benutzer beim Drücken und Ziehen alle Änderungen an allen Objekten vornehmen.

In Git gibt es nur einen Pool von Objekten und diese Tracking-Dateien (Zweige/Köpfe), die bestimmen, welcher Satz dieser Objekte den Dateibaum in einem bestimmten Zustand darstellt.Beim Schieben oder Ziehen sendet Git nur die Objekte, die für die jeweiligen Zweige benötigt werden, die Sie schieben oder ziehen. Dabei handelt es sich um eine kleine Teilmenge aller Objekte.

Was Git betrifft, gibt es kein „1-Projekt“.Sie könnten alle 50 Projekte im selben Repo haben, und es wäre Git egal.Jeder konnte separat im selben Repo verwaltet werden und problemlos funktionieren.

Hgs Zweigstellenkonzept besteht aus Zweigen vom Hauptprojekt oder Zweigen von Zweigen usw.Git hat kein solches Konzept.Ein Zweig in Git ist nur ein Zustand des Baums, alles ist ein Zweig in Git.Welcher Zweig offiziell, aktuell oder neu ist, hat in Git keine Bedeutung.

Ich weiß nicht, ob das irgendeinen Sinn ergab.Wenn ich Bilder zeichnen könnte, könnte hg so aussehen, wo jeder Commit ein ist o

             o---o---o
            /        
o---o---o---o---o---o---o---o
         \         /
          o---o---o

Ein Baum mit einer einzigen Wurzel und von ihm abgehenden Ästen.Während Git das kann und es oft auf diese Weise verwendet wird, wird dies nicht erzwungen.Ein Git-Bild, wenn es so etwas gibt, könnte leicht so aussehen

o---o---o---o---o

o---o---o---o
         \
          o---o

o---o---o---o

Tatsächlich macht es in mancher Hinsicht nicht einmal Sinn, Zweige in Git anzuzeigen.

Eine Sache, die für die Diskussion sehr verwirrend ist: Git und Mercurial haben beide so etwas wie einen „Zweig“, aber sie sind nicht im Entferntesten dasselbe.Ein Branch in Mercurial entsteht, wenn es Konflikte zwischen verschiedenen Repos gibt.Ein Zweig in Git ähnelt offenbar einem Klon in Hg.Aber ein Klon, auch wenn er ein ähnliches Verhalten hervorrufen könnte, ist definitiv nicht dasselbe.Erwägen Sie, dass ich diese in Git vs. HG mit dem Chromium-Repo ausprobiere, 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 Durchgang.hg clone ist eigentlich dasselbe wie git-new-workdir.Beides erstellt ein völlig neues Arbeitsverzeichnis, fast so, als ob Sie es eingegeben hätten cp -r project project-clone.Das ist nicht dasselbe wie das Erstellen eines neuen Zweigs in Git.Es ist viel schwerer.Wenn es ein echtes Äquivalent der Git-Verzweigung in hg gibt, weiß ich nicht, was es ist.

Ich verstehe HG und Git einigermaßen könnte in der Lage sein, ähnliche Dinge zu tun.Wenn ja, dann gibt es immer noch einen großen Unterschied im Arbeitsablauf, zu dem Sie geführt werden.In Git besteht der typische Arbeitsablauf 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

Dadurch wurden gerade drei Zweige erstellt, die jeweils auf einem Zweig namens „Master“ basieren.(Ich bin mir sicher, dass es in Git eine Möglichkeit gibt, jeweils eine Zeile anstelle von zwei zu erstellen.)

Jetzt arbeite ich einfach an einem

git checkout fix-game-save-bug

und fang an zu arbeiten.Dinge begehen usw.Der Wechsel zwischen Zweigen erfolgt selbst in einem so großen Projekt wie Chrome nahezu augenblicklich.Ich weiß eigentlich nicht, wie man das in HG macht.Es ist nicht Teil der Tutorials, die ich gelesen habe.

Ein weiterer großer Unterschied.Gits Bühne.

Git hat diese Idee einer Bühne.Sie können es sich wie einen versteckten Ordner vorstellen.Beim Commit übertragen Sie nur das, was sich auf der Bühne befindet, nicht die Änderungen in Ihrem Arbeitsbaum.Das mag seltsam klingen.Wenn Sie alle Änderungen in Ihrem Arbeitsbaum übernehmen möchten, würden Sie dies tun git commit -a Dadurch werden alle geänderten Dateien zur Bühne hinzugefügt und anschließend festgeschrieben.

Was ist dann der Sinn der Bühne?Sie können Ihre Commits ganz einfach trennen.Stellen Sie sich vor, Sie haben joypad.cpp und gamesave.cpp bearbeitet und möchten sie 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 verfügt sogar über Befehle, um zu entscheiden, welche bestimmten Zeilen in derselben Datei Sie auf die Bühne kopieren möchten, sodass Sie diese Commits auch separat aufteilen können.Warum willst du das tun?Denn als separate Commits können andere nur diejenigen abrufen, die sie möchten, oder wenn ein Problem aufgetreten ist, können sie nur den Commit zurücksetzen, bei dem das Problem aufgetreten ist.

Im versioncontrolblog gibt es eine dynamische Vergleichstabelle, in der Sie verschiedene Versionskontrollsysteme vergleichen können.

Hier ist eine Vergleichstabelle zwischen git, hg und bzr.

Bei der Arbeit mit Filialen (insbesondere kurzfristigen) gibt es durchaus erhebliche Unterschiede.

Es wird in erklärt dieser Artikel (BranchingExplained) welches Mercurial mit Git vergleicht.

Gibt es an Ihrem Projekt Windows-basierte Mitarbeiter?

Denn wenn ja, wirkt die Git-für-Windows-GUI umständlich, schwierig und unfreundlich.

Im Gegensatz dazu ist Mercurial unter 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, bei github müssen Sie jedoch ein Upgrade auf ein kostenpflichtiges Konto durchführen.Deshalb entscheide ich mich für Bitbucket, das Quecksilber verwendet.

Irgendwann im letzten Jahr habe ich sowohl git als auch hg für meinen eigenen Gebrauch getestet und mich für hg entschieden.Meiner Meinung nach sah es nach einer saubereren Lösung aus und funktionierte damals auf mehr Plattformen besser.Es war jedoch größtenteils ein Fehler.

Vor kurzem habe ich angefangen, Git zu verwenden, weil Git-SVN die Möglichkeit bietet, als Subversion-Client zu fungieren.Das hat mich überzeugt und ich bin jetzt komplett auf Git umgestiegen.Ich denke, dass die Lernkurve etwas höher ist (vor allem, wenn man sich mit den Innenseiten auseinandersetzen muss), aber es ist wirklich ein großartiges System.Ich werde jetzt die beiden Vergleichsartikel lesen, die John gepostet hat.

Ich bin gerade dabei, von SVN zu DVCS zu migrieren (während ich über meine Erkenntnisse blogge, mein erster richtiger Blogging-Ansatz...), und ich habe ein bisschen recherchiert (= gegoogelt).Soweit ich sehen kann, kann man die meisten Dinge mit beiden Paketen machen.Es scheint, als hätte Git ein paar weitere oder besser implementierte erweiterte Funktionen. Ich bin der Meinung, dass die Integration in 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 sie beide Open-Source sind (richtig?), glaube ich nicht, dass es ihnen an wichtigen Funktionen mangeln wird.Wenn etwas wichtig ist, werden die Leute danach fragen und es kodieren.

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 glaube ich nicht, dass beiden wirklich etwas fehlt.

Abgesehen davon bin ich daran interessiert, was andere Leute dazu sagen, da es eine großartige Quelle für meine Blogging-Bemühungen wäre ;-)

Es gibt tolle und ausführliche Vergleichstabellen und Diagramme zu Git, Mercurial und Bazaar unter InfoQs Leitfaden zu DVCS.

Mir ist klar, dass dies nicht 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 dabei spielt, welches Tool besser für die Aufgabe geeignet ist bzw. welches Tool am besten zu „Ihnen“ passt.Das heißt, es sei denn, Sie Wirklich Ich möchte es auf CLI-Art machen.

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.

Diese Frage versuche ich gerade auch für mich selbst zu beantworten..und ich habe die Kandidaten auf Git oder Mercurial reduziert.Ich danke Ihnen allen für die Bereitstellung nützlicher Beiträge zu diesem Thema, ohne dabei religiös zu werden.

Noch ein interessanter Vergleich von Mercurial und Git: Mercurial vs. Git.Der Schwerpunkt liegt auf Interna und deren Einfluss auf den Verzweigungsprozess.

Wenn Sie an einem Leistungsvergleich von Mercurial und Git interessiert sind, schauen Sie sich hier um Dieser Artikel.Das Fazit lautet:

Git und Mercurial liefern beide gute Zahlen, machen aber einen interessanten Kompromiss zwischen Geschwindigkeit und Repository-Größe.Mercurial ist sowohl beim Hinzufügen als auch beim Ändern schnell und hält gleichzeitig das Repository-Wachstum unter Kontrolle.Git ist ebenfalls schnell, aber sein Repository wächst mit geänderten Dateien sehr schnell, bis Sie es neu packen – und diese Neupackungen können sehr langsam sein.Aber das gepackte Repository ist viel kleiner als das von Mercurial.

Die Mercurial-Website hat eine Tolle Beschreibung der Gemeinsamkeiten und Unterschiede zwischen den beiden Systemen und erklärt die Unterschiede im Wortschatz und den zugrunde liegenden Konzepten.Als langjähriger Git-Benutzer hat es mir wirklich geholfen, die Denkweise von Mercurial zu verstehen.

Wenn Sie von SVN migrieren, verwenden Sie Mercurial, da seine Syntax für SVN-Benutzer VIEL verständlicher ist.Ansonsten kann man mit beidem nichts falsch machen.Aber überprüfen Sie es GIT-Tutorial Und HGinit bevor Sie eine davon auswählen.

Dieser Link kann Ihnen helfen, den Unterschied zu verstehenhttp://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/

Manche Leute denken, dass VCS-Systeme kompliziert sein müssen.Sie ermutigen dazu, Begriffe und Konzepte auf dem Gebiet zu erfinden.Sie würden wahrscheinlich denken, dass zahlreiche Doktorarbeiten zu diesem Thema interessant wären.Darunter sind wahrscheinlich diejenigen, die Git entworfen haben.

Mercurial ist mit einer anderen Mentalität konzipiert.Entwickler sollten sich nicht groß um VCS kümmern und stattdessen ihre Zeit auf ihre Hauptfunktion verwenden:Softwareentwicklung.Mercurial ermöglicht es Benutzern, das System zu nutzen und zu missbrauchen, ohne dass sie dabei irreparable Fehler machen.

Jedes professionelle Tool muss über eine klar gestaltete und intuitive CLI verfügen.Mercurial-Benutzer können den Großteil der Arbeit erledigen, indem sie einfache Befehle ohne seltsame Optionen ausführen.In Git Double Dash sind verrückte Optionen die Norm.Mercurial hat einen erheblichen Vorteil, wenn Sie ein CLI-Typ sind (und um ehrlich zu sein, sollte das jeder Software-Ingenieur mit Selbstachtung sein).

Um ein Beispiel zu nennen: Angenommen, Sie führen versehentlich einen 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

Anschließend erhalten Sie eine Meldung, 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 Vorstellung davon, worum es beim Zurücksetzen geht.Darüber hinaus müssen Sie jedoch wissen, was „--soft“- und „--hard“-Resets sind (irgendeine intuitive Vermutung?).Oh, und vergessen Sie natürlich nicht das Zeichen „^“ am Ende!(Was in Ritchies Namen ist das denn...)

Auch die Integration von Mercurial mit Tools von Drittanbietern wie kdiff3 und meld ist viel besser.Generieren Sie Ihre Patches und führen Sie Ihre Zweige ohne großen Aufwand zusammen.Mercurial enthält außerdem einen einfachen http-Server, den Sie durch Eingabe aktivieren

hg serve

Und lassen Sie andere Ihr Repository durchsuchen.

Unterm Strich macht Git das, was Mercurial macht, auf eine viel kompliziertere Art und Weise und mit einer weitaus schlechteren CLI.Verwenden Sie Git, wenn Sie das VCS Ihres Projekts in ein wissenschaftliches Forschungsfeld umwandeln möchten.Verwenden Sie Mercurial, wenn Sie die VCS-Aufgabe erledigen möchten, ohne sich groß darum kümmern zu müssen, und sich auf Ihre eigentlichen Aufgaben konzentrieren möchten.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top