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

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.

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.

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.

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.

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.

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.

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.