Welches DVCS (git oder hg) ist für Programmierer einfacher? [geschlossen]

25

Ein bisschen Kontext: Ich bin im 3. Studienjahr. Die Schüler werden in 4er-Teams eingeteilt. Fast jeder wird unter Windows arbeiten (außer ein paar wie ich, die unter Linux arbeiten). Im Rahmen des Schullehrplans werden wir bald an einem Projekt für einen echten Kunden arbeiten, aber ich und ein anderes Team fragen uns, wie wir unseren Code am besten miteinander teilen können.

Ich arbeite seit 3 ​​Jahren in Teilzeit und habe viel Erfahrung mit Git und Mercurial in verschiedenen Projekten, so dass ich keine Probleme mit dem einen oder anderen System habe. Allerdings hat noch keiner meiner Teamkollegen ein Versionskontrollsystem verwendet. Es gibt auch ein anderes Team, das versucht hat, SVN zu verwenden, aber größere Probleme hatte und es vorziehen würde, etwas anderes auszuprobieren. Deshalb haben sie mich nach meiner Meinung gefragt.

Meine Gedanken: Ich habe gehört, dass mercurial + TortoiseHg eine bessere Integration unter Windows hat, aber ich frage mich, ob das Konzept der anonymen Köpfe sie verwirren könnte, selbst wenn ich sie erkläre. Andererseits finde ich, dass Git-Zweige für Anfänger leichter zu verstehen sind (klare Arbeitsteilung für jeden Programmierer), aber unter Windows nicht so gut funktionieren.

Gregory Eric Sanderson
quelle
2
In git ist standardmäßig eine Menge Leistung aktiviert, aber jeder, von dem ich gesprochen habe, dass es einfacher ist, Quecksilber zu lernen, und ich bin geneigt, aufgrund meiner Erfahrungen mit beiden zuzustimmen. Und ja, die Mercurial-Tools lassen sich unter Windows einfacher installieren als die entsprechenden Git-Tools. Erwarten Sie jedoch, dass Sie die Teilnehmer in der ersten Woche anleiten und auf Tutorials verweisen (oder mehr ...).
wkl
1
Die Verwendung eines DVCS von Anfang an ist wahrscheinlich der einfachste Weg, um das Zusammenführen von Beiträgen mehrerer parallel arbeitender Mitwirkender zu verwalten. Wenn Sie anonyme Köpfe verwirrend finden, verwenden Sie sie nicht (Quecksilber unterstützt benannte Zweige).
Stephen C. Steel
2
Mal wieder auf diesen Blogpost verlinken? Git ist ein Harrier Jump Jet .
sbi
1
Ich habe nie verstanden, warum das Ganze "zu schwer zu lernen" wichtig ist. Okay, es dauert also 20 Minuten, um zu lernen, wie man sich einsetzt und wie man sich verzweigt, im Gegensatz zu 10 ... Große Sache?
Alternative
1
Beobachten Sie, wie einer von ihnen hginit.com durchläuft und Maßnahmen ergreift , die auf ihren Reaktionen beruhen.
Chelmertz

Antworten:

49

Ohne Zweifel Mercurial.

Dies ist natürlich subjektiv und variiert von einer Person zur anderen, aber die allgemeine Meinung ist, dass Mercurial leichter zu erlernen ist, insbesondere für jemanden, der neu bei VCS ist oder aus einem VCS der alten Generation stammt.

Punkte in der Hand:

  1. Mercurial wurde unter Windows entwickelt . Git wurde portiert. Egal, was mir jemand sagen wollte, Git ist immer noch ein zweitklassiger Bürger unter Windows. Die Dinge haben sich in den letzten Jahren zweifellos verbessert, aber Sie sehen immer noch eine Menge Streit darüber, warum etwas unter Windows funktioniert / oder nicht, wie es auf * nix box funktioniert. TortoiseHg funktioniert sehr gut und Visual Studio-Implementierungen sind noch einfacher zu verwenden, ohne den Workflow zu unterbrechen.

  2. Wenn jemand die Diskussion "Git ist mächtiger nach dir ..." startet, dann sagt er so ziemlich alles. Für 95% der Benutzer scheint Mercurial intuitiver zu sein. Ausgehend von einem Mangel an Index zu seinen intuitiveren Optionen (Optionsschalter sind kohärent), zu seinen lokalen Zahlen für Commits anstelle von SHA1-Hashes (wer hat jemals gedacht, dass SHA1-Hashes benutzerfreundlich sind?!)

  3. Mercurials Zweige sind nicht weniger mächtig als Gits. Beitrag, der einige der Unterschiede beschreibt. Das Zurückkehren zu einer früheren Revision ist so einfach wie "Alte Revision aktualisieren". Von dort ausgehend; Mach einfach ein neues Commit. Benannte Zweige sind auch verfügbar, wenn man sie verwenden möchte.

Jetzt weiß ich, dass all dies Details sind und dass man sie lernen kann und alles, aber die Sache ist ... diese Dinge summieren sich. Und am Ende erscheint einer einfacher und intuitiver als der andere. Und das Versionskontrollsystem sollte nicht etwas sein, mit dem man viel Zeit verbringt - Sie sind da, um Programmieren zu lernen und dann zu programmieren. VCS ist ein Werkzeug.

Nur um zu bemerken; Ich benutze täglich Git und Mercurial. Haben Sie keine Probleme mit einem von ihnen. Aber wenn mich jemand um eine Empfehlung bittet, empfehle ich Mercurial immer. Erinnern Sie sich noch, als es zum ersten Mal in meine Hände kam, fühlte es sich sehr intuitiv an. Meiner Erfahrung nach produziert Mercurial nur weniger WTF / Minute als Git.

Turm
quelle
4
+ für "VCS ist ein Werkzeug". Ich hatte die "kleinen Dinge" nicht als Faktor betrachtet, aber es ist wahr, dass kleine Probleme, wenn man sie hier und da aufsummiert, zu einem echten Ärgernis werden können.
Gregory Eric Sanderson
8
"Versionskontrollsystem sollte nicht etwas sein, das man zum Lernen braucht." Das ist eine Menge Mist. Sie sollten immer Zeit damit verbringen, Ihre Werkzeuge zu erlernen. Sie verbringen Zeit damit, Ihren Compiler zu lernen. Das VCS ist jedoch ein ebenso wichtiges Werkzeug für Ihre Programmierung wie Ihr Compiler.
JesperE
9
+1. Besonders das Argument "Bürger zweiter Klasse für Windows" ist in dieser Situation absolut wichtig.
tdammers
+1 für "WTF (s) / Minute" ( osnews.com/story/19266/WTFs_m ). Diese Kinder müssen die Fähigkeiten lernen :-)
Ross Patterson
1
@Mark, das ist nur das Ergebnis eines terminologischen Unterschieds ... Ein Zweig in Git ist eigentlich nur ein Name.
Alternative
10

Ich habe festgestellt, dass die TortoiseHg-Benutzeroberfläche unter Windows eine großartige Erfahrung ist. Als ich in der Vergangenheit mit Git experimentiert habe, bin ich stattdessen zur Kommandozeile gegangen. Für einen durchschnittlichen Benutzer ist eine gute Benutzeroberfläche viel zugänglicher als eine Befehlszeile. Also würde ich vorschlagen, Mercurial zu verwenden. (Es enthält auch ein nettes Verzweigungsdiagramm im Workbench-Fenster. Es sollte alle grundlegenden Verzweigungsschwierigkeiten beseitigen.)

Sobald sie die Dinge aus der Sicht der Benutzeroberfläche verstanden haben, gelangen sie möglicherweise zur Befehlszeile, um Skripts zu erstellen oder manuelle Vorgänge auszuführen. Dies ist jedoch nicht erforderlich.

John Fisher
quelle
Da ich selbst ein "Konsolen-Junkie" bin, habe ich die Tortoise {Svn, Git, Hg} -Anwendungen noch nie benutzt, also wusste ich nicht, dass TortoiseHg eine Zweiggrafik hat. Ich muss das überprüfen
Gregory Eric Sanderson
4

Wenn Sie an einer dritten Option interessiert sind, würde ich Fossil vorschlagen . Ich finde, dass die Möglichkeit, einen temporären Webserver zum Teilen von Code zu starten, in kleinen Projekten großartig ist. Fossil ist nur eine ausführbare Datei, daher können Sie es und Ihre Quelle auf ein USB-Stick speichern und von jedem Universitätscomputer aus verwenden.

Verwenden Sie fossil uidiese Option, um einen temporären Webserver überall dort zu starten, wo Sie möchten, dass Ihre Kommilitonen mit Ihnen synchronisiert werden. Es bietet Ihnen auch ein Ticketsystem, ein Wiki und eine benutzerfreundliche Weboberfläche zum Ändern von Zweigen und zum Kennzeichnen von Commits.

Stellen Sie einfach sicher, dass sie die Kurzanleitung und / oder das Buch lesen . Schließlich gibt es ein Projekt namens winFossil , um ihnen eine benutzerfreundlichere Oberfläche als die Web-Benutzeroberfläche zu bieten.

Spencer Rathbun
quelle
Ich habe gute Dinge über Fossilien gehört, aber leider habe ich nicht so viel Zeit, um mich mit einem neuen DVCS vertraut zu machen. Ich bevorzuge es, etwas zu verwenden, an das ich gewöhnt bin (wenn möglich), da ich bereits weiß, wie man die häufigsten Fallstricke umgeht. Aber danke für den Vorschlag, ich werde es mir auf jeden Fall ansehen, sobald ich die Zeit dazu habe.
Gregory Eric Sanderson
+1; Fossil ist nur wenig bekannt , aber es ist so einfach zu arbeiten und so in sich geschlossene (+ DVSC Wiki + + Karten Webserver) , dass es ist eine echte Alternative zu den gesamten trac oder sogar GitHub.
Javier
Aber Fossilien werden im Lebenslauf der Schüler nicht so gut aussehen wie Git oder Hg, da es nur sehr wenige Menschen schwer haben.
Ian
Mercurial hat auch eine integrierte HP-Servefunktionalität. Es fehlt natürlich ein Bug-Tracker und ein Wiki. Aber dann gibt es auch bitbucket.com
Johannes Rudolph
3

Angesichts der Tatsache, dass die Teams neu in der Versionskontrolle sind und viele Windows verwenden, würde ich mercurial over git empfehlen.

Das konzeptionelle Modell der Versionskontrolle, das von Git und Mercurial verwendet wird, ist sehr ähnlich. Wenn Sie eines beherrschen, ist es einfach, das andere zu übernehmen (und aus ähnlichen Gründen ist es ziemlich einfach, ein Repository von einem in das andere zu konvertieren). . Dies bedeutet, dass es keine große Sache ist, wenn Sie Ihre Meinung später ändern.

Meiner Meinung nach ist Quecksilber für neue Benutzer leichter zu lernen. Es macht einfache Dinge leicht und gefährliche Dinge schwer. Git macht gefährliche Operationen einfach (einfach zu machen, nicht unbedingt einfach richtig zu machen!).

Die TortoiseHg-Oberfläche für Windows ist auch sehr schön und ein weiteres Argument für die Verwendung von Quecksilber.

Stephen C. Steel
quelle
2

Meine persönliche Präferenz ist für git.

Da jedoch einige Benutzer Windows verwenden und das hervorragende Hginit- Lernprogramm vorhanden ist, empfehle ich, sie in Quecksilber zu unterrichten.

dan_waterworth
quelle
+1 für die Erwähnung von Hginit. Obwohl Pro Git auch ziemlich gut ist.
Tamás Szelei
@ TamásSzelei, Danke, ich hatte Pro Git noch nie gesehen.
Dan_waterworth
0

Wie viele Leute vorgeschlagen haben, Mercurial über TortoiseHg eine sehr niedrige Eintrittsbarriere.

Für diejenigen, die unter Windows arbeiten, ist es ein einzelner Installer anstatt zwei Installer (und eine ganze Menge Dinge, die sie vielleicht nicht lernen möchten), und die THg-Benutzeroberfläche ist viel ausgefeilter als TortoiseGit + Msysgit .

Anonyme Köpfe

Wenn Sie glauben, dass sie von anonymen Köpfen verwirrt werden, empfehlen Sie deren Verwendung nicht. Die meistenhg Büchern wird ein ausgewogener Ansatz verfolgt, bei dem sowohl topologische als auch benannte Zweige vermittelt werden. Der Leser kann dann bestimmen, welche für seine Verwendung am besten geeignet sind.

Benannte Zweige

Eine Sache, die ich wirklich vermisse, gitsind hgdie benannten Zweige , das ist also eine Option.gitZweige sind in Ordnung, während Sie daran arbeiten. Wenn Sie diese Arbeit jedoch zu einem anderen Zweig zusammengeführt haben, verlieren Sie einen Großteil des Kontexts für diese Änderungen.

In hgkönnten Sie einen Zweig namens erstellen Jira#1234und immer in der Lage sein, alle mit diesem Fix verbundenen Revisionen zu finden . Imgit , sobald Ihre Niederlassung in und der Schiedsrichter gelöscht zusammengeführt wird, müssen Sie folgern , welche Revisionen Teil des Updates von der Topologie des Revisionsbaum waren. Auch wenn Sie den Verweis nicht löschen, kennen Sie immer noch nur den letzten Commit für diesen Zweig, nicht den Vorfahren, der Teil dieser Commit-Kette war.

Lesezeichen

Alternativ können Sie Lesezeichen verwenden , wenn Sie keine benannten Zweige verwenden möchten, aber einen gitStilworkflow mit anonymen Zweigen möchten stattdessen verwenden.

Dies könnte das Beste aus beiden Welten sein - sie lernen einen gitWorkflow, können jedoch die einfacheren hgBefehle verwenden.

Index / Cache / Staging-Bereich

Persönlich denke ich, dass Studenten viel eher durch den gitIndex- / Cache- / Staging-Bereich verwirrt werden als durch hgdie anonymen Köpfe. Ich bevorzuge hges sehr , diese erweiterte Funktionalität in der Befehlszeile optional zu machen, anstatt gitdavon auszugehen , dass Sie sie immer verwenden möchten / müssen.

Ich denke auch, dass der Staging-Bereich Commits fördert, die noch nicht getestet oder kompiliert wurden. Da viele der Orte , die ich gearbeitet habe hatte eine nicht begehen , wenn es nicht kompilieren lässt Regel, würde ich viel lieber shelve / Stash ändert Ich will nicht gerade jetzt, re-run Unit - Tests und begehen eine Version , dass Ich weiß, kompiliert.

Wenn Sie später einen Fehler mit hg bisect oder git bisect aufspüren , werden Sie sich bedanken, dass Sie alle Revisionen testen können, nicht nur die, die kompiliert werden.

Mark Booth
quelle
Sie müssen den Git-Zweig nicht löschen, nachdem Sie fertig sind. es ist nur Brauch. Außerdem -1 für die Fehlinterpretation von Verwendungen des Index - Sie verwenden ihn nicht zum Bereitstellen fehlerhafter Festschreibungen, sondern zum Bereitstellen von Teilschritten einer größeren Reihe von Festschreibungen. Normalerweise geschieht dies während eines Rebases, wenn Sie Ihren Verlauf löschen.
Alternative
@mathepic - Wenn Sie keine Filialnamen löschen und alle Ihre lokalen 'Fix'-Filialen auf Remote verschieben, werden Sie eine große Anzahl von Refs erhalten, genau wie Sie am Ende eine Vielzahl alter Filialen haben in svn. In hgdiesen Zweigen sind Namen immer topologisch lokal, sodass Sie sie nur sehen, wenn Sie sie suchen.
Mark Booth
@mathepic - Bezüglich Ihrer -1 denke ich, dass Sie falsch interpretieren, was ich sage. Ich kann mir nicht vorstellen, warum jemand absichtlich ein schlechtes Commit machen würde, aber mit git ist es einfach, es aus Versehen zu tun. Wenn Sie diese Datei vergessen cimplementiert eine modifizierte Schnittstelle in der Datei iund versehentlich die begehen , iohne cdann , wenn jemand zieht in Ihre Änderungen , bevor Sie zu begehen , haben um cihre Kompilierung fehl. Wenn Sie stattdessen den Workflow stash / compile / commit verwenden, wird dieser Fehler einfach nicht auftreten, da Ihr eigener Build zuerst unterbrochen wird. Ich habe versucht, meine Antwort klarer zu machen.
Mark Booth