Git, Hg oder Bzr - Was ist einem neuen Benutzer zu empfehlen?

Question

Ich habe einige Freunde, die möglicherweise daran interessiert sind, ein Versionskontrollsystem für unsere bevorstehenden Masterarbeiten (Latex-Dokumente und verschiedene Programmierungen) zu erlernen. Ich spreche hier nicht von irgendetwas Großem und Kompliziertem, sondern nur davon, es für Backups, das Betrachten alter Revisionen und einige grundlegende Verzweigungen und Zusammenführungen zu verwenden.

Ich denke jedoch, dass es eine gute Idee ist, eine zu wählen, die für einen Anfänger leicht zu erlernen ist. Die Frage ist also, welches Versionskontrollsystem würden Sie jemandem empfehlen, der neu in solchen Dingen ist, um es zu lernen?

Ich persönlich habe Git und Mercurial ein bisschen benutzt und im Moment denke ich, dass ich zu Mercurial tendiere. Bazaar habe ich allerdings noch nicht ausprobiert.

Soweit meine Eindrücke zu den für neue Benutzer geeigneten Funktionen:

Mercurial

Vorteile:

• Nummerierung der Revisionen
• Einfaches Auschecken eines alten Commits, Bearbeiten und Einfügen
• Einfaches Zusammenführen direkt mit einem Mergetool
• Einfache Verzweigung (?)
• Schöne Plugins wie glog

Nachteile:

• Zweige und Lesezeichen können beide für das verwendet werden, was Git als Verzweigung bezeichnet - das könnte ein wenig verwirrend sein
• Gibt nicht viele Informationen darüber, was bei der Ausführung eines Befehls geschieht/falsch ist

Git

Vorteile:

• Vollständige Kontrolle (zumindest wird der Eindruck erweckt)
• Ausführliche Hilfe und Informationen, wenn etwas schief geht

Nachteile:

• Einige schwierige Konzepte (wie der Bereitstellungsraum)
• Einige Verzweigungsoperationen können etwas schwierig sein

Basar

Ich habe es noch nicht ausprobiert...

Was meinen Sie dazu? Bitte folgen Sie dem gute subjektive Leitlinien hier bei der Beantwortung.

Answer 1

Die letzten Leute, denen ich Versionskontrolle von Grund auf beigebracht habe, waren mit git (einschließlich meiner Tochter, als sie etwa 12 Jahre alt war). Ich habe auch neuen Benutzern Mercurial beigebracht.

Für jemanden ohne Erfahrung mit Versionskontrolle waren beide gleich einfach. Für jemanden, der von Subversion oder CVS enttäuscht wurde, war git anfangs schwieriger (abhängig von ihrer Bereitschaft, die Grundlagen zu verstehen vs. blind Dinge funktionieren zu lassen, war git jedoch ziemlich einfach).

Basierend darauf, und einigen der anderen Antworten hier und meinen eigenen persönlichen Vorurteilen, denke ich, dass git die beste Lösung ist. Allein auf Github gibt es fast zwei Millionen git-Repositories. Es wird nicht so schnell verschwinden.

Answer 2

Was du als einen der Vorteile von Mercurial angenommen hast - die Revisionsnummerierung - wird von vielen Menschen als Nachteil angesehen. Und was du als Nachteil von git angenommen hast - den Zwischenbereich; als schwieriges Konzept betrachtet - wird von vielen Menschen als Vorteil angesehen.

Also ist das nicht so einfach.

Aber wenn du mich fragst - Mercurial ist James Bond, wie es ein Blogger genannt hat - es ist elegant und auf einer höheren Ebene als git, zumindest auf den ersten Blick. Außerdem sind seine Befehle ziemlich ähnlich wie die Subversion-Befehle, daher könnten neue Benutzer, die von svn konvertieren, Mercurial viel schneller lernen als git.

Answer 3

Ich denke nicht, dass deine Freunde einen großen Unterschied bei einem der drei VCS bemerken werden. Wenn es nur als einfaches Backup mit einer geringen Anzahl von Branches verwendet wird (wahrscheinlich sowieso nicht konfliktreich), spielt es keine Rolle, für welches Tool sie sich entscheiden. Alle drei können einfache Aufgaben ohne spezielle Kenntnisse des Benutzers erledigen.

Vor allem, wenn die Leute völlig neu im Umgang mit Versionskontrolle sind, gibt es keinen wirklichen Grund, ein Tool dem anderen vorzuziehen. Obwohl sie alle etwas unterschiedliche Konzepte verwenden (wobei Git wahrscheinlich das speziellste ist), ist es kaum etwas, was ein neuer Benutzer ohne Erfahrung mit den anderen Tools bemerken wird.

Die Verteilung deiner aufgelisteten Vor- und Nachteile (die übrigens nicht wirklich stimmen) sagt mir, dass du mit Mercurial mehr oder tiefere Erfahrungen hast als mit Git. Deshalb würde ich empfehlen, Mercurial zu verwenden, denn falls deine Freunde Hilfe benötigen, können sie dich fragen und du wirst ihnen aufgrund deiner eigenen Erfahrungen eine gute Antwort geben können.

Ich denke, das ist wichtiger als die Gesamtanzahl der Benutzer im Internet oder auf einigen Hilfeseiten (übrigens könnte die hohe Anzahl von Git-Fragen auch bedeuten, dass Git für viele Leute verwirrender ist - was wahrscheinlich zutrifft).

Ein weiterer Faktor bei der Entscheidung für ein Tool für unerfahrene Benutzer, insbesondere wenn diese es möglicherweise nicht wirklich oft in ihrem Leben brauchen, könnte die Verfügbarkeit einer einfachen grafischen Benutzeroberfläche sein. Es könnte sogar eine gute Integration mit ihrem TeX-Editor geben, was sie dazu bringen würde, ein bestimmtes Tool einem anderen vorzuziehen.

Answer 4

Empfehlen Sie denjenigen, den Sie am besten kennen. Wenn Sie einem Bekannten einen empfehlen möchten, sollten Sie bereit sein, als Erster ihre Fragen zu beantworten. Mercurial, Git und Bazaar sind alle großartig und bei weitem besser als nichts. Wenn sie jemals eine Lücke feststellen, können sie eines der anderen ausprobieren, aber ehrlich gesagt, um anzufangen, "Machts nichts!"

Answer 5

Ich werde meine Erfahrung mit Git und Mercurial weitergeben, in beiden Fällen beginnend von Grund auf.

Ich habe mich entschieden, mein Team (5 Top-Entwickler, einschließlich mir, die alle diszipliniert sind) von ClearCase (UCM, aber sie hatten alle sowohl die Basisversion von ClearCase als auch UCM über mehrere Jahre verwendet) umzustellen. Nachdem ich mir alle 3 Optionen von Mercurial, Git und Bazaar angesehen hatte, entschied ich mich für Mercurial (stark beeinflusst durch PEP 374).

Innerhalb einer Woche fühlte ich mich sicher genug, um Mercurial in die Teamprozesse einzuführen, und die Leute begannen damit, es zu verwenden. Die größte Herausforderung bestand darin, sicherzustellen, dass ich weiterhin Änderungen upstream an ClearCase senden konnte. Das gesamte Team hat es schnell übernommen, und wir haben sofort eine Veränderung in unserer Arbeitsweise bemerkt.

Wir haben eine sehr verzweigte Entwicklung (einen benannten Branch pro Aufgabe) verwendet - im Grunde vererbt von der Arbeitsweise von ClearCase, aber wir fanden heraus, dass dies eine gute Arbeitsweise für das Team war (Anmerkung - viele Hg-Benutzer würden diese Branche-Strategie nicht mögen). Ein Entwickler würde an einer Aufgabe arbeiten und sie zur Überprüfung an jemand anderen senden. Früher durchging der Überprüfende alles und machte Notizen usw. und schickte sie dann zurück an den ursprünglichen Entwickler, aber mit Mercurial stellten wir fest, dass wir einfach den Branch wechselten, überprüften, und dann den Autor einbezogen und gemeinsam in der Umgebung des Überprüfenden die Änderungen machten (Paar-Programmierung) und sie demselben benannten Branch bestätigten.

Insgesamt dauerte es etwa 2 Wochen, bis das gesamte Team unter meiner Anleitung von Grund auf einsatzbereit war.

Meine Erfahrung mit Git ist jünger - ich habe erst vor etwa 2 Monaten angefangen, es zu nutzen (nachdem ich bereits beträchtliche Erfahrung mit Mercurial hatte). Ich habe jedoch vor etwa 2 Monaten angefangen, es zu nutzen, und erst jetzt beginne ich mich damit einigermaßen wohl zu fühlen. Das größte, was mich bei Git unsicher macht, ist, dass Git davon ausgeht, dass du die Historie bearbeiten wirst, und das sehr einfach macht. Ich muss regelmäßig Teile der git Hilfe/Anleitung lesen, um sicherzustellen, dass ich die Dinge "richtig" mache. Ich finde das System mit dem lokalen Branch + Remote-Tracking-Branch sehr fremd und unlogisch, während das Branching in Mercurial unglaublich einfach ist (um herauszufinden, wo du im Vergleich zu einem anderen Repo stehst, fragst du es einfach).

Das Team, mit dem ich arbeite, fühlt sich genauso. Git wurde als VCS festgelegt, aber ich wurde nun gebeten, uns am Ende der aktuellen Arbeitsphase zu Mercurial umzustellen.