Was ist der Unterschied zwischen Mercurial und Git?

727

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.

Spoike
quelle

Antworten:

345

Diese Artikel können helfen:

Edit : Der Vergleich von Git und Mercurial mit Prominenten scheint ein Trend zu sein. Hier ist noch eine:

jfs
quelle
1
"Git vs Mercurial Please Relax" ist ernsthaft veraltet, obwohl es so alt ist wie diese Frage. Vielleicht sollte diese Frage gelöscht und erneut geöffnet werden, nachdem beiden Tools mehr als 3 Jahre Funktionen hinzugefügt wurden.
Gman
238

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.

Martin Geisler
quelle
21
Beachten Sie, dass TortoiseHg auch mit Nautilus, dem Gnome-Dateimanager unter Linux, zusammenarbeitet.
Oenli
4
Das Ruby-Skript wird nur generiert, wenn es sich bei dem httpd um Webrick, den Ruby-Webserver, handelt.
Alternative
4
Wie Git speichert Mercurial beim Festschreiben Snapshots Ihrer Dateien. Ich bin nicht damit einverstanden, dass Umbenennungen nur mit einer Heuristik wie in Git verfolgt werden können. Das Modell enthält nichts, was das Hinzufügen zusätzlicher Informationen zu einem Snapshot ausschließt, z. B. das Umbenennen von Informationen. Das machen wir in Mercurial.
Martin Geisler
63
Um ein nicht verwandtes Projekt mit git zusammenzuführen (zu ziehen), können Sie einfach : git pull <url-of-project>. Die Mail, die Sie zitiert haben, stammt aus den frühen Tagen von Git (2005)
Knittl
5
knittl: ah, gut, ich bin froh zu hören, dass Git weniger arkan wird. Trotzdem denke ich, dass das Beispiel ein bisschen zeigt, wie sich die Systeme darin unterscheiden, was wir für cool halten, und Git fühlt sich für mich im Vergleich zu Mercurial niedriger an (aber nicht leistungsfähiger).
Martin Geisler
73

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.

Aristoteles Pagaltzis
quelle
78
Ich habe oft gelesen, dass Leute Git als "Plattform" erwähnen, aber das ist eher eine Theorie oder ein verbreiteter Mythos, weil es keine wichtigen Beispiele dafür als Plattform gibt, um etwas anderes zu tun als Git zu betreiben.
Ian Kelling
@ Ian - Wenn ich mich nicht irre, verwendet Aptana Studio 3 es für sein internes Update-System.
Mac
22
Kurz gesagt: Mercurial ist ein Open-Source-System zur verteilten Revisionskontrolle, und Git ist eine Wahl für den Lebensstil.
Tim Keating
51

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.

mmiika
quelle
64
"Nativ" ist also nicht ganz das richtige Wort, aber es wird unter Windows nicht gut unterstützt, das ist sicher.
Ian Kelling
14
Git wird bis zu einem gewissen Punkt unter Windows unterstützt. Versuchen Sie jedoch, plattformübergreifende Unicode-Dateinamen zu verwenden, und sehen Sie, welche Schmerzen Sie bekommen.
Craig McQueen
@Craig: Das ist eher ein Plattformmangel. Eine kompetente Plattform würde es Ihnen ermöglichen, zu einem geeigneten Gebietsschema zu wechseln. Wenn Sie sich an utf-8 halten, werden Sie meistens in Ordnung sein, außer dass Mac OS X eine etwas andere Normalisierung von utf-8 hat. Ich bin mir jedoch nicht sicher, ob Sie in Windows überhaupt utf-8 verwenden können ...
Arafangion
23
Windows unterstützt Unicode, obwohl MS sich für UTF-16 in seiner API anstelle von UTF-8 entschieden hat. Trotzdem wäre es für git durchaus möglich, Unicode plattformübergreifend zu unterstützen. SVN hat dieses Problem recht gut gelöst. Für die msysGit-Entwicklung hat dies derzeit jedoch keine hohe Priorität. code.google.com/p/msysgit/issues/detail?id=80
Craig McQueen
38

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.

Maurice Flanagan
quelle
1
Ich folgte dem gleichen Tutorial. Es ist definitiv.
Nathan
20

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.

Arialdo Martini
quelle
6
Dies ist kein Unterschied; Hg hat auch Zweige benannt. Wir verwenden sie die ganze Zeit während der normalen Entwicklung anstelle von Klonzweigen.
Deestan
2
AFAIK, benannter Zweig in Hg, wird erhalten, indem Metadaten in jedem Commit gespeichert werden; Ich kann mich irren, aber ich habe gelesen, dass nach dem Erstellen eines Zweigs dessen Metadaten in jeden Änderungssatz eingebettet werden und Teil des Verlaufs werden. Das ist ein großer Unterschied zu Git. "Klone eignen sich hervorragend für schnelle Experimente, bei denen Sie keinen Zweignamen aufzeichnen möchten, und benannte Zweige eignen sich für Langzeitzweige" tinyurl.com/2wz39qx Was ich mit meinem Beitrag sagen wollte, ist, dass der Standard-Workflow von git Sie einlädt eine einzige Arbeitskopie verwenden; Der Standard-Workflow von Hg umfasst Klone, die nicht meinen persönlichen Anforderungen entsprechen.
Arialdo Martini
Eine gute Erklärung der Ähnlichkeiten / Unterschiede
bezüglich der
2
benannte Zweige in hg sind nichts anderes als Zweige in git. In hg gibt es einen wahren Weg. Alle Zweige sind Zweige von diesem Weg. In Git gibt es keinen wahren Weg. Es gibt nur verschiedene Zustände des Repos und Zeiger auf diesen Zustand. Jeder Zweig ist nur ein anderer Zeiger. Welcher Zeiger der Hauptzeiger ist, kann verwendet werden. Zweige sind alle Peers.
Gman
17

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.

FelipeC
quelle
29
Der Vorteil von Changesets (Diffs) besteht darin, dass weniger Platz benötigt wird. Git stellt den für Commits verwendeten Speicherplatz mithilfe der Komprimierung wieder her. Dies erfordert jedoch gelegentlich einen expliziten Schritt zur erneuten Komprimierung ("Git Pack").
Quark
8
Es heißt jetzt 'git gc', aber es gibt verschiedene Ebenen der Speicherbereinigung, und einige Ebenen werden in neueren Versionen von git automatisch ausgeführt.
FelipeC
6
Eigentlich verwendet Mercurial auch Schnappschüsse
Ronny
13
Ich verstehe den Unterschied, den Sie zwischen "Schnappschüssen" und "Unterschieden" machen, nicht. Sowohl hg als auch git store werden als (Gruppen von) Dateideltas festgeschrieben . Diese Deltas basieren auf der vorherigen Revision, die das jeweilige SCM auswählt. Haben Sie Zahlen, die zeigen, dass Git für die von Ihnen erwähnten Operationen tatsächlich schneller ist? Das Aktualisieren auf ein anderes Commit verbringt die meiste Zeit damit, in das Arbeitsverzeichnis zu schreiben und das Repo sowieso nicht zu lesen.
Kevin
2
'Snapshot's vs.' Diff's - völlig irrelevant. Das intern gespeicherte Repo hat jedoch keinen Einfluss darauf, was der Benutzer sieht. Sowohl Git als auch Mercurial präsentieren dem Benutzer Schnappschüsse. Es gibt keinen Grund, warum ein Repository-Format, das auf die gleiche Weise wie git implementiert wurde, nicht zu mercurial hinzugefügt werden konnte, so wie ich es bei Bazaar glaube.
Mark Booth
11

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 .

dbr
quelle
6
Ihre Antwort war anscheinend viel zu pragmatisch. :)
Arafangion
11

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.

gman
quelle
"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." Was sind diese Befehle?
James McMahon
1
@ James :, git add --patchsiehe linux.die.net/man/1/git-add oder verwenden Sie git add -i, wie in stackoverflow.com/questions/2372583/…
Tanascius
@gman: Anstatt den Master auszuchecken und mit ihm zu verzweigen checkout -b <name>, könnten Sie einfach git branch <name>einen neuen Zweig erstellen, ohne zu ihm zu
wechseln
8

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

Hier ist eine Vergleichstabelle zwischen git, hg und bzr.

Spoike
quelle
1
Die Informationen zu Mercurial sind nicht ganz korrekt: Mercurial verfügt über "intelligente Zusammenführungen nach Verschiebungen oder Umbenennungen". Konkret bedeutet dies , dass , wenn ich umbenennen 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.
Martin Geisler
Die Informationen (es stammt aus dem Vergleich der Better SCM Initiative , IIRC) über Git sind an einigen Stellen ebenfalls ungenau oder sogar ungenau.
Jakub Narębski
7

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.

Johnbasil
quelle
Ich mag Git, aber ich muss hier zustimmen. Git hat eine schönere Kommandozeile mit der Bühne und eine bessere Dokumentation. Ich würde gerne die git-Befehle mit einer Posix-Shell verwenden. TortoiseHG unter Windows ist zwar großartig, es lässt sich sogar in mehrere Diff-Tools integrieren (unvergleichlich) und bietet volle Unterstützung für Sub-Repos sowie viele HG-Plugins wie Strip /
MQ
Es gibt mindestens eine sehr gute Git-GUI für Windows (und OS X + Linux).
Mot
7

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.

Spielzeug
quelle
5

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.

Greg Hewgill
quelle
4
Schauen Sie sich hgsubversion an: bitbucket.org/durin42/hgsubversion . Derzeit ist eine Entwicklungsversion von Mercurial erforderlich, es wird jedoch eine Veröffentlichung für Mercurial 1.3 veröffentlicht, die am 1. Juli fällig ist.
Martin Geisler
4

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 ;-)

Erik van Brakel
quelle
1
Ja, beide sind Open-Source-Projekte.
Martin Geisler
4

Im InfoQ-Handbuch zu DVCS finden Sie eine großartige und umfassende Vergleichstabelle und -tabelle zu git, Mercurial und Bazaar .

Spoike
quelle
3

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.

joho
quelle
2
+1, weil die "nahtlose" Erfahrung wichtiger ist als Leute denken, die nicht mit diesen Dingen arbeiten. Ein solides Plugin für die IDE macht einen großen Unterschied.
Eksortso
2

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

Konstantin
quelle
2

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.

Asmaier
quelle
2

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.

Johndodo
quelle
1

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.

Kostas
quelle
1
Tatsächlich können Sie Befehle in git aliasen , was die Verwendung der CLI weniger kompliziert macht. In dieser SuperUser-Frage (StackExchange) gibt es einige davon .
Spoike
1
Ja, Sie können auch Shell-Skripte schreiben, um einige allgemeine Aufgaben zu erledigen. Irgendwann wird Ihnen klar, dass Sie eine Wrapper-CLI erstellen, um mit einem VCS umzugehen, das über eine schlecht gestaltete und kontraintuitive CLI verfügt. Und das ist nicht nur das. Git führt eine Vielzahl von Konzepten mit fragwürdiger Benutzerfreundlichkeit ein, die der Benutzer schließlich lernen und verstehen muss, um sich mit Dokumentation und CLI-Nachrichten vertraut zu machen.
Kostas