Warum hat Git so viel Hype bekommen? ... während andere es nicht tun? [geschlossen]

124

In den letzten Jahren hat der Hype um Git stark zugenommen. Jeder kennt Git, niemand kennt Alternativen.

Andere wie Mercurial scheinen unbemerkt zu sein. Beide wurden 2005 veröffentlicht und bieten ähnliche Funktionen. Darüber hinaus wird Mercurial allgemein als benutzerfreundlicher, intuitiver angesehen und bietet seit langem bessere Benutzeroberflächen. Daher ist davon auszugehen, dass dies eine beliebte Alternative ist, insbesondere für diejenigen, die neu in der verteilten Versionskontrolle sind. Trotzdem scheint es den meisten Leuten unbekannt zu sein, im Gegensatz zu Git, das ziemlich gut gelungen ist.

In diesem Beitrag geht es darum, dieses Phänomen besser zu verstehen.

Wie kommt es, dass Git einen Teil des Kuchens bekommt? Haben sie irgendwie besseres Marketing eingesetzt? Liegt es daran, dass seine Community mehr ... ähm ... "wortreich" ist? Liegt es am Namen "Linus"? Liegt es an seinem geekigen Image?

Was ist deine Meinung?

Arnaud
quelle
63
Sie haben möglicherweise Recht, dass Linus Torvalds der einzige Grund für seine Beliebtheit ist ...
Robert Koritnik
4
Ich weiß nicht, ich habe das Gefühl, dass sie mir in ungefähr gleichen Mengen ausgesetzt waren ... obwohl ich vor hg schon von git gehört habe. Aber ja, Torvalds ist eine Berühmtheit, und alles, woran er beteiligt ist, wird wahrscheinlich Aufmerksamkeit erregen.
Perp
13
Ich mag GitHub ... das ist alles
und
7
@jrwren, vorab möchte ich sagen, dass ich weder Git noch Mercurial verwendet habe. Wenn ich Git lernen und dann sofort Mercurial (oder umgekehrt) lernen würde, würde einer von ihnen wahrscheinlich weniger Zeit zum Lernen brauchen. Dieser, der weniger Zeit in Anspruch nahm, ist meiner Meinung nach einfacher zu bedienen. Grokking impliziert normalerweise, dass das Verstehen einige Zeit in Anspruch nimmt, was daher schwieriger zu handhaben ist. Ich sage nicht, dass dies ein Produkt verschlimmern würde. Manchmal benötigen Sie eine steilere Lernkurve für leistungsfähigere Werkzeuge, aber dies ändert zweifellos die Benutzerfreundlichkeit.
zzzzBov
8
@ MarkTrapp Gott, Markus! Sieht so aus, als hätten alle eine gute Diskussion geführt, und dann mussten Sie mitkommen und alle vor der Tür überwachen. Ich wünschte, ich wüsste von einer Site wie StackOverflow, die Diskussionen zulässt.
Theodore R. Smith

Antworten:

86

Ich glaube, dass Dienste wie GitHub oder Gitorious ein großer Faktor sind. Es ist wichtig für die Leute, dass sie ihre Sachen irgendwo hosten können und besonders GitHub ist ein großartiger Service dafür.

Für Mercurial gab es keinen solchen Dienst, als DVCS populär wurde (zumindest keiner, von dem ich wusste). Du hast jetzt Bitbucket und wahrscheinlich auch andere, aber GitHub ist schon eine ganze Weile da, es ist bekannt und wird immer besser.

daaawx
quelle
Hinzu kommt, dass einige große Open-Source-Projekte Git verwenden, das die Entscheidung für Sie trifft. Ich war "gezwungen", Git mehrmals zu benutzen (zum Beispiel für Android), aber ich war nicht gezwungen, Mercurial oder Bazaar zu benutzen. Außerdem finde ich git is great :)
FeatureCreep
11
Es gibt auch Google Code und SourceForge für hg
Konfigurator
7
Git wird von Github unterstützt, das andere Repositories in den Schatten stellt. Bitbucket hat einige Vorteile (kostenlose private Repositories), aber die Benutzeroberfläche ist schlecht im Vergleich zu Github
iandotkelly
2
Ich verwende Mercurial alleine, um mit GitHub zu sprechen ... das hggit-Plugin ( hg-git.github.com ) ermöglicht es, das Tool von der Community zu entkoppeln. Aber vielleicht nicht aus den Community-Tools.
Bpanulla
1
CodePlex unterstützt auch Mercurial.
Grant Palin
86

Ich sehe viele Antworten darauf, die sich auf die Gefühle des Autors stützen, als er von dem einen oder anderen SCM hörte. Andere sagen, alles sei Glück gewesen. Ich glaube, dass Glück in der Geschichte zurückverfolgt werden kann.

Ich werde über die Geschichte sprechen.

Git und Mercurial wurden gleichzeitig erstellt, um das gleiche Problem zu lösen. Damals war der Linux-Kernel gezwungen, BitKeeper , ein proprietäres verteiltes SCM, das er seit drei Jahren verwendet, nicht mehr zu verwenden. Der Grund dafür war, dass Larry McVoy, CEO von BitMover, dem Unternehmen, das hinter BitKeeper steht, seine Software nicht mehr kostenlos an Linux-Entwickler weitergibt, weil jemand in der Linux-Community sie rückentwickelt hatte.

Linus Torvalds, der mit dem, was bereits existierte, unzufrieden war, begann daraufhin, an einem brandneuen SCM zu arbeiten, den er bald Git nennen würde. Kurz darauf startete Matt Mackall aus ähnlichen Gründen das Mercurial-Projekt.

Nachdem Matt Mackall diese Projekte einige Zeit separat entwickelt hatte, präsentierte er eine erweiterte Version seines SCM und bewertete sie auf eine bestimmte Weise als Benchmark. Er verglich sie mit Git (der selbst erst ein paar Wochen alt war). Linus erwog, es anstelle von Git für die Kernel-Entwicklung zu verwenden, ließ die Idee jedoch fallen, als er feststellte, dass Mercurial Changesets verwendete, um Revisionsänderungen zu protokollieren . Er befürchtete, dass dies der Arbeitsweise von BitKeeper zu nahe käme, und er wollte auf keinen Fall, dass jemand sagen könnte: "Sie haben einen BitKeeper-Klon erstellt".

Git wurde daher für die Kernel-Entwicklung anstelle von Mercurial verwendet, aber beide waren technisch relevant. Das Endergebnis ist, dass Git ursprünglich dort eingesetzt wurde, wo es eingesetzt werden sollte, während Mercurial seine erste große Verwendung für FOSS nicht so schnell fand. Weil es mit einem sehr guten Design ausgestattet war und dank Matt Mackalls Beharrlichkeit wurde es schließlich berühmt und wurde für große Projekte in der realen Welt verwendet.

Heute sind beide berühmt. Welches am bekanntesten ist, lässt sich nicht sagen. Google Code hat Git erst kürzlich integriert, während es lange Zeit Mercurial gab. Viele wirklich große und berühmte Projekte verwenden beide.

Ich denke, was ich meine ist, wenn der Grund, warum Sie ein Projekt gestartet haben, verschwindet, ist es schwieriger, an Popularität zu gewinnen, aber immer noch machbar.

Bazaar ist ein weiteres SCM, das in der GNU-Welt sehr berühmt ist, aber nicht so sehr darüber hinaus, weil es mit der Absicht gebaut wurde, die GNU-Community zufriedenzustellen. Software geht oft dahin, wohin ihre Entwickler wollen, und nicht weiter.

Andererseits sind verteilte SCMs klare Gewinner. Ich sehe nicht viele weit verbreitete nicht verteilte SCMs da draußen.

Thaddee Tyl
quelle
5
Ich schätze diese Geschichte sehr.
Jrwren
4
@TMN Du hast recht! Als Andrew Tridgells Reverse-Engineering ans Licht kam und Larry McVoy die Lizenzierung von BitKeeper änderte, gab es so viele Flammenkriege, dass Linus Torvalds beschloss, sie fallen zu lassen und sich eine Woche Zeit ließ, um einen Ersatz zu finden. Zu der Zeit war der echte Konkurrent Monotone, aber es war tränenreich langsam. Viele Leute bauten gleichzeitig Ersatz und alle waren einfach glücklich, die neuen Werkzeuge zu benutzen. Ich denke, Git schlug zuerst 1.0, dann Mercurial; Basar dauerte fast zwei Jahre.
Thaddee Tyl
7
"Ich sehe nicht viele weit verbreitete nicht verteilte SCMs da draußen." Es hängt davon ab, wo Sie in der Branche sind. Perforce, ClearCase und svn sind immer noch sehr weit verbreitet, nur nicht so häufig (außer svn) in der Open Source-Welt. Oh ja, und Visual Source Safe und MS Team, was auch immer in Windows-Shops erhältlich ist.
Bob Murphy
13
Mit "Reverse Engineering" meinen Sie das Telneten mit dem Server und das Eingeben von "help"
alternative
3
Ich würde dies allgemein über DVCS und CVCS sagen: "Alle Software-Teile des Tao und sollten nicht verachtet werden." "Einschließlich Software von Redmond?" "Oh mein Gott, sieh auf die Uhr. Klasse entlassen."
Bob Murphy
77

Linus Torvalds

Linus ist ein großer Befürworter von Git und hat es jahrelang stark in die Linux-Kerngruppe aufgenommen und ist von dort gewachsen. Ich gehe davon aus, dass es ganz auf Linus 'Einfluss auf die * nix-Community zurückzuführen ist.

Persönlich benutze ich immer noch Subversion, aber das ist eher eine Vorliebe als eine Nützlichkeit.

Justin Shield
quelle
12
Ich denke nicht, dass es Linus persönlich ist, sondern die enorme Sichtbarkeit von Linux - Es gibt einige Dinge, die Sie jemandem sagen können, der keine Vorkenntnisse zu DVCS (oder sogar zur Softwareentwicklung im Allgemeinen) hat und die eher Glaubwürdigkeit verleihen als "es wird für das" Linux Kernel".
Michael Borgwardt
6
Er ist nicht nur ein großer Verfechter davon - er ist derjenige, der die Originalversionen erstellt hat, bevor er sie Junio ​​Hamano übergab
Marco Ceppi
44
Was? Warum bevorzugen Sie Subversion?
Konfigurator
11
Meinst du nicht, dass du Subversion immer noch aus Gewohnheit und Trägheit anstatt aus Präferenz oder Nutzen benutzt? Deshalb benutze ich es immer noch und ich vermute auch, dass der größte Teil von uns ...
Cody Gray
7
@deadalnix: Weil Linux und Linux eine Horde schreiender Fanboys haben, die von keinem anderen Open-Source-Projekt übertroffen werden. Sie fungieren als ziemlich effektives Straßenteam für Git.
Tom Anderson
34

Das übliche Problem bei Versionskontrollsystemen ist das Zusammenführen von Zweigen .

Sie müssen es probiert haben, wenn es nicht funktioniert, um zu verstehen, wie schmerzhaft es sein kann und wie wichtig es ist, arbeiten zu müssen, um frei mit Zweigen arbeiten zu können.

Zu erfahren, dass Linus Torvalds git geschrieben hat, um dies richtig zu machen, und dass er angeblich in einer Situation git verwendet hat, um zwölf Zweige gleichzeitig zusammenzuführen, ist ein sehr überzeugendes Argument dafür, dass git interessant ist.

Ich befand mich vor ungefähr einem Jahr in einer Situation, in der ich mich zwischen hg und git entscheiden musste, und die obige Verschmelzung war ein wichtiger Faktor bei der Auswahl von git. Das zweite Problem war, dass die Eclipse-Organisation auf Git umstellte, sodass erwartet wurde, dass das Eclipse-Tool für Java-Projekte geeignet ist. Mit der Veröffentlichung von Eclipse 3.7 ist dies geschehen. Wir waren vielleicht 6-9 Monate zu früh dran.

Für unterschiedliche Bedürfnisse könnte hg genauso nützlich sein. Sun entschied sich aufgrund einer sehr sorgfältigen Untersuchung für das VCS . Vielleicht möchten Sie die White Papers finden und sehen, was ihre Argumente waren.


EDIT: Beachten Sie, ich sage nicht, dass Mercurial etwas nicht kann, nur dass für Java mit Eclipse - was unser Hauptaugenmerk ist - die Marktkräfte für Git derzeit am stärksten sind, auch unter Windows, und wir müssen auf den Schultern stehen von anderen nicht ihre Füße.

user1249
quelle
5
+1 Es ist alles in den Filialen. Diese Analyse erörtert die Verschmelzungskraft von Git im Vergleich zu Quecksilber.
Amelio Vazquez-Reina
19
@AmV: Veröffentlichen Sie keine verschleierten URLs.
Cody Grey
4
Ich bin mir nicht sicher, ob ich deinen Standpunkt hier sehe. Sie sagen, dass sie gleich gut in der Verzweigung sind (Git macht nichts, was Mercurial nicht kann), aber weil Sie eine gute Verzweigung brauchen, haben Sie Git gewählt?
Jalf
8
Ich habe noch nie überzeugende Beispiele dafür gesehen, wie Git besser fusionieren kann als Mercurial, und schon gar nicht in dieser Antwort. Es ist fast so, als würden Sie Hg mit SVN oder CVS verwechseln.
Aaronaught
23

Anstatt zu sagen, warum Git oder Quecksilber besser sind, und zu sagen, dass es der einzige Grund ist, warum es beliebt ist, werde ich mich auf die Community konzentrieren.

Wie ich bereits erwähnt habe , ist die Git-Community sehr laut und arrogant. Die meisten werden ihr kostbares Programm energisch verteidigen. Die meisten Git gegen Mercurial-Kriege, die ich gesehen habe, wurden von Git-Leuten gestartet, die sich fragten, warum nicht jeder auf der Erde den heiligen Git benutzt. Sites wie whygitisbetterthanx.com zeigen diese Arroganz sogar in der Einleitung, die geschrieben wurde, um andere zu flammen.

Ich sage nicht, dass jeder so ist, aber die meiste Zeit, wenn ich auf Git-Leute, Git-Websites und Git-Blogs gestoßen bin, hatte ich das Gefühl, dass Git mir in den Rachen geschoben wird, anstatt es als brauchbares DVCS anzubieten System.


Im Gegensatz dazu sind andere DVCS-Communities nicht so laut. Ich wusste nicht, dass Mercurial existiert, bis ich ein "Whats the best DVCS?" Frage zu SO. Während Git überall erscheint, brauchen andere DVCS Zeit, um es zu finden.

TheLQ
quelle
16
Ist es nicht ein bisschen arrogant, andere arrogant zu nennen?
21
@ Thorbjørn: Es ist. Außer wenn ich es tue; dann ist es einfach richtig.
Tom Anderson
6
Ich denke, Sie sind ziemlich allergisch gegen Schwachsinn geworden. Ich habe die Einführung von whygitisbetterthanx und einige seiner Inhalte gelesen. Ich sehe nichts Arrogantes oder Provokatives. Es hat einfach die normale Voreingenommenheit, die alles hat, was dazu bestimmt ist, etwas zu fördern.
back2dos
5
@ back2dos: es ist ziemlich arrogant, dass es behauptet "Git ist besser als alles". Und dabei sind ziemlich große Teile seiner Argumentation entweder falsch und unkorrigiert oder durchgestrichen, und doch ändert es irgendwie nie ihre Schlussfolgerung.
Jalf
5
@Agos: Und fast alle davon sind nicht Git- spezifisch . Sie bewegen einfach die Torpfosten , um andere Produkte auszuschließen.
Aaronaught
14

Ich denke nicht, dass Mercurial besonders unauffällig ist. Der Brennofen ist auf Hg aufgebaut und IDEs wie Eclipse & Netbeans bieten seit einiger Zeit gute Unterstützung.

Die meisten Entwickler, mit denen ich spreche, scheinen Hg wegen der besseren Windows-Unterstützung zu bevorzugen. Wenn wir Linux-Entwickler wären, könnte das eine andere Geschichte sein.

Sie vermissen auch "Bazaar", das ist das echte "vergessene DVCS".

Ich bin mir sicher einig, dass Linus ein sehr charismatischer Typ und ein Alpha-Nerd ist, der seinesgleichen sucht, so dass viele Leute sich deswegen für Git interessieren würden. Außerdem ist der "Schöpfungsmythos" von Git sehr überzeugend, da Linus 6 Tage lang daran arbeitet, Git zu erschaffen und sich auf dem siebten auszuruhen - oder so ähnlich. Wenn ein Produkt eine einprägsame Geschichte hat, ist es einfacher, Traktion zu erlangen.

mcottle
quelle
6
... stimme voll und ganz zu: "Bazaar" ist das echte "vergessene DVCS".
dagnelies
Ich stimme zu, aber die Belichtung von Brennofen / Joel ist jünger als die von Linus. hg spielt catchup
jk.
2
Es gibt tatsächlich eine ganze Reihe von "vergessenen DVCS", von denen viele wahrscheinlich besser als "Low Profile", "Focused" oder "Niche" beschrieben werden.
John Gaines Jr.
13

Es ist eine bescheidene Meinung, aber git könnte diesen ganzen Hype wegen zweier Parameter bekommen:

  1. Es ist sehr effizient
  2. Es macht Spaß, es zu benutzen (auf eine ganz bestimmte Art und Weise eines Informatikers)

Außerdem hat git eine Killer-App wie github und einige sehr beliebte Projekte haben sich für die Verwendung entschieden, was ihm viel Sichtbarkeit verleiht.

Thibault J
quelle
4
1. Ist Quecksilber in manchen Gebieten ineffizient? Tatsächlich war es lange Zeit über http effizienter, weshalb Google Code es seit mehr als 2 Jahren einbezog, verglichen mit der Git-Unterstützung, die letzte Woche angekündigt wurde und über http erst kürzlich gleich gut wurde. 2. OK 3. Es gibt das Äquivalent bitbucket.org
dagnelies
1
Habe ich gesagt, dass Quecksilber ineffizient ist? Ich habe es nie benutzt, damit ich es beurteilen kann.
Thibault J
4
Dies spricht die Frage überhaupt nicht an, zumindest nicht das "während andere es nicht taten"
jk.
1
Mercurial kann dem Repository keine "leeren Ordner" hinzufügen (keine Ahnung, ob dies jetzt behoben wurde), aber als ich mich für ein DVCS entscheiden musste, habe ich mich für diesen Zweck entschieden. Ich brauchte leere Ordner.
Martin Marconcini
4
@ MartínMarconcini Was meinst du mit "Ich bin zu diesem Zweck irgendwann zum Trottel gegangen"? git unterstützt auch keine leeren Ordner.
Max Nanasy
12

Hier spielen drei Faktoren eine Rolle: "Beta Geek Media", "Die Zeit ist gekommen" und "Follow the Leader".

Beta Geek Media

Es gibt eine Reihe von Kanälen, die über "Geeky-Aktivitäten" diskutieren. Sie würden sicherlich das Erscheinen eines neuen Versionskontrollsystems abdecken, aber sie decken mehr Git ab. Warum? Weil Linus Torvalds es ursprünglich geschrieben, öffentlich diskutiert und als Lösung für sein bekanntes Problem mit Bitkeeper verwendet hat. Tatsächlich werden die Beta-Geek-Medien immer dann einen Artikel darüber schreiben, wenn es einen Flammenkrieg auf lkml gibt. Die Git-Diskussion begann auf lkml, sodass mehr Aufmerksamkeit auf sich gezogen wurde als auf andere Alternativen. Und die Beta-Freaks, die Slashdot lesen, als wäre es Variety, haben es aufgefressen. Das Endergebnis davon ist, dass Git zehnmal so viele Artikel enthält wie Quecksilber.

Es ist jetzt Zeit

Große Open Source-Projekte mit vielen Mitwirkenden haben Probleme mit der zentralen Quellcodeverwaltung. Wenn Open Source wächst und Projekte mit größerer Wahrscheinlichkeit viele Mitwirkende haben, wird das Problem noch schlimmer. Linux ist wahrscheinlich das bekannteste Projekt, das darunter leidet, aber es gibt viele andere. Da viele Projekte diesen Punkt erreichten, wurde eine Art fortgeschrittenes VCS benötigt. Git, Mercurial und Bazaar waren hier die großen Gewinner. Arch und Monotone waren etwas zu früh und ließen die Hype-Welle aus.

Folgen sie den Anführer

In großen Projekten gibt es Follower, die den Code regelmäßig auschecken und erstellen, auch wenn sie keinen Beitrag leisten. Die Follower werden mit den Tools vertraut gemacht, die zum Abrufen des Projekts, dem sie folgen, erforderlich sind, damit diese Tools häufiger verwendet werden. Werfen wir einen Blick auf die "Big Draw" -Projekte für die drei großen DVCS:

  • Git : Linux, Perl, jQuery, Ruby auf Schienen, Eclipse, Gnome, KDE, QT, X
  • Mercurial : Java, Mozilla, Python
  • Basar : Ubuntu, Emacs

Git verwendet mehr "Big Draw" -Projekte, so dass mehr Leute mit Git vertraut sind und mehr Git-Tutorials geschrieben wurden.

Sean McMillan
quelle
1
Sie mögen Recht haben, aber Ihre "Big Draw" -Liste ist etwas irreführend / voreingenommen. Wenn man sich die Bazaar-Site ansieht, werden noch einige andere wichtige Projekte aufgelistet: MySQL, Bugzilla, Debian und GNU scheinen alle ziemlich weithin bekannt zu sein. Die Hg-Liste ist auch ziemlich viel größer.
Jalf
@jalf: eine solche liste muss subjektiv sein. Ich habe mein eigenes Linux und Gnome kompiliert, aber niemals Mozilla oder Emacs. Andere mögen genau umgekehrt sein. Die Frage ist wirklich: "Wie viele Leute werden dieses Projekt aus der Quellcodeverwaltung entfernen?" Ich habe diejenigen aufgelistet, die mich am ehesten dazu inspirieren, ein vcs zu installieren, um die aktuelle Quelle zu ziehen.
Sean McMillan
Fair genug. Ich nahm an, dass es ein Versuch war, eine objektive Liste zu erstellen (schließlich sollte es einfach genug sein, zu ermitteln, in welchen Hauptprojekten jedes DVCS-System verwendet wird) :)
jalf
12

Es ist hauptsächlich ein sich selbst verstärkender Hype. Git ist am beliebtesten, daher wird es am bekanntesten, was dazu führt, dass es immer beliebter wird.

Git, Hg und Bzr sind allesamt einwandfreie DVCS-Systeme, aber eine erschreckende Zahl von Menschen setzt DVCS mit Git gleich und denkt, dass alle schönen Funktionen eines DVCS nur Git eigen sind. Und so verwenden sie Git und empfehlen Git und sagen Dinge wie "Git ist besser, weil es Octopus Merges machen kann" (so kann Bazaar) oder "Git ist besser, weil es verteilt ist" (so ist jedes DVCS, daher der Name) ) oder "Git ist besser, weil es das Verzweigen und Zusammenführen erleichtert" (auch dies gilt für jedes DVCS).

Leider, weil ich der Meinung bin, dass die Alternativen auch viel zu bieten haben und die Leute Git lieber wegen seiner einzigartigen Stärken wählen, als einfach, weil sie DVCS == Git denken.

Wenn jemand herausfindet, wie schlau DVCS sind, sagt er anderen oft nicht, "hey, DVCS sind großartig, Sie sollten sie verwenden", sondern "das DVCS, das ich verwende Englisch: www.mjfriendship.de/en/index.php?op...41&Itemid=32 Von DVCS gelernt zu haben ist großartig, man sollte es benutzen ".

Jalf
quelle
11

Github. Github ist ein Pionier in Sachen Social Coding. Es hat die Versionskontrolle in eine soziale Plattform verwandelt, die viel Aufmerksamkeit auf sich gezogen hat, und es unterstützt offensichtlich nur Git. Social Media = mehr Akzeptanz. Bitbucket gewinnt an Fahrt, obwohl es viele neue Funktionen gibt, was es wahrscheinlich zu einem Rivalen macht :)

DelvarWorld
quelle
7

Tatsächlich denke ich, dass der Hype um alle DSVCs geht.

Aber die GIT-Befürworter sind nur lauter, oft aggressiver in ihren Kommentaren, um ehrlich zu sein und reden gerne überall darüber.

Ich vermute, dass Mercurial weit verbreitet ist, sicherlich genauso oft wie Git, vielleicht sogar mehr (Microsoft und andere große Unternehmen setzen es jetzt ein), aber die Leute, die Mercurial verwenden, wollten meist nur eine DSVC, die sie schnell verstehen können, und nicht etwas, worauf sie eine Religion gründen können. So sind sie am wenigsten lautstark und reaktionsfreudiger in Diskussionen als proaktiv wie manche Git-User.

Über Bazaar wird mit Sicherheit nicht viel geredet, da es nur von wenigen bekannten Projekten und von keinem anderen großen Unternehmen als Canonical verwendet wird. Vergleichen Sie zum Beispiel mit Google (Git, Mercurial, Svn) und großen Open-Source-Projekten, und Sie können sehen, warum nicht wirklich darüber gesprochen wird. Fossil ist eine andere, die für eine Nische von Entwicklern interessant ist. Ich denke, es ist normal und in Ordnung, dass sie nur von denen gehört werden, die die von ihnen bereitgestellten Funktionen durchsuchen (wie eingebettetes Wiki, Problemverfolgung und Forum).

Abgesehen davon denke ich, dass wir langsam den Hype-Zyklus durchlaufen und viele Entwickler, die mehrere verschiedene Lösungen verwendet haben, feststellen können, welche ihren Anforderungen entsprechen.

Außerdem erlauben Google Code Hosting und SourceForge jetzt sowohl Git als auch Mercurial, sodass es aufgrund der GitHub-Funktionen eine projektspezifischere Wahl ist als zuvor.

Es gibt keinen wirklichen Krieg, nur eine interessante Auswahl an Werkzeugen.

Klaim
quelle
Ich wünschte, der Hype hätte generell mit DVCS zu tun, aber nach allem, was ich gesehen habe, geht es um Git, und die meisten Leute denken, dass DVCS und Git im Grunde dasselbe sind.
Jalf
6

Ich weiß, dass es bereits viele Antworten auf diese Frage gibt, aber ich hatte das Gefühl, ich könnte etwas mehr Perspektive hinzufügen.

Ich habe Bazaar ziemlich oft benutzt, seitdem es für verschiedene Zwecke entwickelt wurde. Das Größte, wofür ich es verwendet habe, war das "MiniTay" -Projekt, für das ich (derzeit) der einzige Entwickler und Betreuer bin. Basar ist schön. Es funktioniert einfach, es steht mir nicht im Weg und ich muss fast nie auf eine Hilfeseite oder die Manpage dafür schauen. Das heißt, es gibt einige Nachteile:

  1. Viel Funktionalität, die es hat und die wohl Teil des Kern-VCS sein sollte, ist es nicht. Dinge wie die Möglichkeit, eine Halbierung des Verlaufs durchzuführen, lange Ausgaben über einen Pager auszuführen oder "kolokalisierte" Zweige (z. B. Repositorys im Git-Stil) als Plugins bereitzustellen.
  2. Viele der Plugins sind nicht so stabil. Zum Beispiel scheint die Funktion für kolokalisierte Zweige auf der Serverseite nicht gut zu funktionieren (zumindest habe ich sie nie zum Laufen gebracht; es kann leicht vorkommen, dass der Zweig auf dem angegebenen Pfad nicht existiert, wenn er vorhanden ist genau dort vor dir und du kannst das verdammte Ding sehen).
  3. Es gibt keine "Klon" -Operation, Sie ziehen die Zweige nacheinander. Sie müssen zusätzliche Arbeit leisten, wenn Sie ein Repository haben möchten, damit Sie neue Zweige effizient ziehen können.
  4. Für einige Projekte ist es schmerzhaft langsam. Versuchen Sie einmal "bzr branch lp: mysql".
  5. Es fehlt starke Unterstützung für Haken; Sie können bzr-Plugins schreiben, die Hooks bereitstellen, aber es gibt keine Standardmethode für serverseitige willkürliche Hookskripte.

Ich bin vor kurzem für die Entwicklung von Jeday auf Git umgestiegen und überlege mir sehr schnell, alle meine Projekte auf Git zu migrieren . Es ist etwas mehr Zeit im Vorfeld, um die Seile kennenzulernen, aber es scheint sich zu lohnen. Einige Dinge, die mir aufgefallen sind:

  1. git clone Dies ist eine relativ schnelle Operation und gibt Ihnen Informationen zu allen Zweigen, die in dem von Ihnen geklonten Repository vorhanden sind.
  2. Das Hinzufügen zusätzlicher Remote-Repositorys ist mühelos, sodass Sie viele verschiedene Repositorys mit mehreren Zweigen nachverfolgen können, wenn Sie dies wünschen.
  3. Das Pro Git- Buch ist online und in verschiedenen Formaten erhältlich, auch für eBook-Lesegeräte - und es ist keine schwierige Lektüre.
  4. Git scheint viel einfacher zu erweitern zu sein als Bazaar, und Sie müssen keine bestimmte API verwenden, um dies zu tun. (Hinweis: Dies ist sowohl ein Aufwärts- als auch ein Abwärtspfeiler.)
  5. In Git ist eine Halbierung integriert, und ich kann die Nützlichkeit dieser Funktion nicht genug betonen.
  6. GitHub ist ziemlich nett.
  7. Das gitosisSystem ist auch ganz nett. Ich bin mir nicht mal sicher, wie man das anders als als Plugin in Bazaar implementieren würde, und ich kann mir nicht vorstellen, dass es bei weitem nicht so effizient wäre.

Lange Rede, kurzer Sinn: Ich habe bzr sehr lange benutzt, aber git zeigt mir schnell, wie großartig es ist.

Michael Trausch
quelle
5

Mit git bleiben Sie bei der Entwicklung in der Regel immer im selben lokalen Verzeichnis und git checkout branchnamewechseln einfach zwischen Zweigen (ich verwende die ganze Zeit "Lightweight" -Feature-Zweige, daher ist dies für mich ein sehr wichtiges Feature).

Betrachtet man die Mercurial-Dokumentation und die Tutorials, so scheint es, dass der bevorzugte Weg, mit verschiedenen Entwicklungszweigen umzugehen, darin besteht, neue Repositorys durch Klonen zu erstellen. Dieses Tutorial ist ein Beispiel.

Ich glaube, Sie können in Mercurial dasselbe tun wie in git, aber aus irgendeinem Grund zeigt die Mercurial-Dokumentation (die ich gelesen habe) fast immer Verzweigungen, indem Sie einen Repository-Klon erstellen.

(Ich benutze Git täglich. Ich habe wenig Erfahrung mit Quecksilber, ich habe damit gespielt und bin ein paar Tutorials gefolgt.)

codeape
quelle
2
Ich habe die ganze Zeit 'named' Äste in hg benutzt. Es unterstützt sie gut. hg branch foo, dann hg up foospäter ... Clone-for-Branch hat einige starke Schwächen für die normale Entwicklung.
Paul Nathan
Hmm, Sie sagen also, dass Git besser ist als Hg, weil Hg zwar die Funktion unterstützt, die Sie interessiert, die Hg-Community jedoch einen alternativen Ansatz für überlegen hält?
Jalf
1
1: Ich frage mich: Warum der Fokus auf "Verzweigen durch Klonen" in der HG- Dokumentation (siehe zum Beispiel hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html und mercurial.selenic). com / guide )? Für mich scheint es nur chaotisch, ein Repository pro Zweig zu haben. 2: Ich sage nicht, dass git besser ist, meine Antwort ist eher eine Beobachtung in einer Angelegenheit, die für mich (einen Hg-Neuling) wie ein Unterschied zwischen den beiden aussieht. Der Unterschied scheint eher kultureller als technischer Natur zu sein, da Hg auch "branch within same repository" unterstützt.
codeape
3
Mercurial leidet unter vielen veralteten Online-Informationen. Vieles davon wurde von Leuten propagiert, die git verwenden und sich im Laufe der Entwicklung nicht über die Funktionen von mercurial auf dem Laufenden halten. Die meisten der alten Gründe, geklonte Repositorys zu bevorzugen, gelten in modernen Versionen von Mercurial nicht mehr (benannte Zweige können jetzt geschlossen werden, und es gibt ein Lesezeichensystem, das Ihnen ein ähnliches Verwendungsmuster wie Git-Zweige gibt, wenn Sie möchten).
Stephen M. Redd
4

Ich weiß nicht, wie viele solcher Beschimpfungen ich in den letzten Wochen gesehen habe, aber alle scheinen es als Tatsache zu betrachten, dass Mercurial und / oder Bazaar objektiv besser sind als Git. Benutzerfreundlichkeit scheint ein gemeinsames Thema zu sein. Ja, Git zu lernen war nach der Verwendung von CVS und Subversion überraschend schwer, aber an diesem Punkt würde ich es nicht gegen ein anderes VCS eintauschen wollen, es sei denn, es war ein weiterer Paradigmenwechsel . Wenn ich auf eine Tabelle mit Funktionen zeige, erfahre ich kaum, wie flexibel, erweiterbar, sicher oder mühelos sie sind. Zum Beispiel standardmäßig git-diff verwendet Farben und einen Pager. Klar kann ich das gleiche mit diff ... | colordiff | less -Roder so bekommen, aber es sollte klar sein, warum einer dem anderen überlegen ist.

l0b0
quelle
Ich denke nicht, dass das Argument ist, dass Sie deshalb wechseln sollten - offensichtlich ist es einfacher, das Tool zu verwenden, von dem Sie bereits wissen, dass es einfacher ist, auf ein anderes zu wechseln, egal wie einfach das andere ist. Ich glaube nicht, dass ein DVCS-Befürworter wirklich behaupten könnte, dass Sie eine riesige Menge verpassen, wenn Sie auf Git statt Bazaar oder Mercurial sind. Es gibt nicht so viel zwischen ihnen.
ZoFreX
3

Um ehrlich zu sein, denke ich, dass die Befürworter von Git gegen Quecksilber im Vergleich zu den Befürwortern von Git gegen Zentralisierte nur wenige und weit voneinander entfernt sind. Die Gründe lassen sich jedoch leicht zusammenfassen:

Git ist die Versionskontrolle für Programmierer. Mercurial ist die Versionskontrolle für Unternehmen. Zentralisiert war ein adäquater erster Versuch, die Versionskontrolle zu erfinden, vor allem, wenn man bedenkt, dass sie vor der Revolution des Personalcomputers entwickelt wurde.

Was ich unter Versionskontrolle für Programmierer verstehe, ist, dass Programmierer im Allgemeinen Flexibilität gegenüber einfachem Lernen bevorzugen. Schließlich sind wir bereit, Jahre damit zu verbringen, esoterische Sprachen zu lernen, um die Flexibilität zu haben, Computer dazu zu bringen, das zu tun, was Ungeübte nicht können. Git gibt Programmierern die Flexibilität, es zu verwenden, wie es ihnen gefällt, auf Kosten dessen, dass es länger dauert, um zu lernen, wie man diese Flexibilität sicher verwendet. Es ermöglicht die Einführung von Einschränkungen zur Durchsetzung von Richtlinien, ist jedoch nicht sofort einsatzbereit. Hinweis: Ich habe gesagt, dass das Lernen einfacher ist als die Bedienung . Sobald Sie es gelernt haben, ist git so einfach zu bedienen wie jedes andere VCS und aufgrund der höheren Geschwindigkeit und Funktionen oft einfacher.

Einige Programmierer lernen genug, um das zu tun, was sie wollen, und widersetzen sich dann dem Erlernen neuer Methoden. Unternehmen stellen viele dieser Mitarbeiter ein und beschäftigen sie. Daher möchten sie, dass die von ihnen verwendeten Tools in gewissem Maße vertraut sind. Unternehmen möchten auch, dass ihre Programmierer genügend Flexibilität haben, um ihre Arbeit zu erledigen, aber nicht so sehr, dass Schulungen oder die anfängliche Migration erschwert werden. Hier fügt sich Quecksilber ein. Es hat die meiste Kraft von Git, aber einen etwas einfacheren Migrationspfad.

Ich denke nicht, dass es fair ist zu sagen, dass Git nur wegen des Hype oder der Unterstützung von Linus beliebt ist. Das erklärt wahrscheinlich, dass viele Leute es versuchen , aber sie bleiben dabei und fördern es, weil es schlicht und einfach gut für sie funktioniert.

Karl Bielefeldt
quelle
2

Die NetBSD-Entwicklung verwendet CVS und das ist alles, was wichtig ist.

Jonathan Cline IEEE
quelle
2

Es hat einen knackigeren, markigeren Namen, der sich gut für Wortspiele eignet.

Apophenie-Überladung
quelle
1

Ich habe vor kurzem nach einem Versionskontrollsystem für persönliche Projekte gesucht, also habe ich nur ein paar davon ausprobiert. Ich bin praktisch Analphabet auf der Kommandozeile, und ich hatte gehört, dass, obwohl GUIs verfügbar waren, Git wirklich für die Verwendung über die Kommandozeile gedacht war, was mich ein bisschen zögerlich machte. Ehrlich gesagt, es war unglaublich einfach, es aufzunehmen, und ich genieße es wirklich. Die Dokumentation ist ein wichtiger Faktor bei der Einführung einer neuen Technologie, und Git hat jede Menge lächerlich einfacher Dokumentationen, die klar und verfügbar sind. Die anderen Alternativen wie SVN und Bazaar waren großartig, sie machten es einfach nicht so einfach wie Git. Github ist auch ein großer Faktor, da es im Moment so zentral für die Open-Source-Bewegung geworden ist. Ein (ironischerweise) zentraler Ort für den Austausch von Code und Projekten zu haben, ist an sich schon ein Umbruch.

Morgan Herlocker
quelle
1

Nur meine 2 - Ich habe mich für git entschieden, weil es in C geschrieben ist und nicht in einer Radtool-Sprache oder einer zu akademischen Hochsprache. Die Vorteile sind, dass es schnell und effizient ist und ich RTFS kann, wenn ich auf Bugs oder Verhalten stoße, die ich nicht erklären kann. Es macht es auch möglich, auf winzigen selbst gehosteten Entwicklungsumgebungen zu arbeiten, die keine riesigen Interpreter / Runtimes enthalten, was bedeutet, dass ich direkt von einem Git-Repo-System abrufen und auf solchen Systemen kompilieren kann, anstatt die neueste Quelle woanders abrufen und rsync ausführen zu müssen.

R ..
quelle
1
Das war auch der Grund, warum ich mich für git entschieden habe, weil es in einer kompilierten Sprache anstatt in Python geschrieben ist und deshalb ich einfach eine portable Version von git zusammen mit einigen anderen Tools in meinem USB-Stift haben kann.
Coyote21
Und doch ist dies genau der Grund , warum Facebook entschied sich stattdessen Mercurial zu verwenden: sie sind nicht zufrieden mit der Leistung der beiden waren, fand aber einfacher ist es , die Leistung von Mercurial zu verbessern (was für die meisten Operationen war, nur ein kleiner Prozentsatz langsamer als git overall) um ein Vielfaches (was sie getan haben, indem sie es in einen Dateiüberwachungsdienst integriert haben, um zu erkennen , was sich geändert haben könnte und was nicht, siehe Details hier ), weil Python einfacher zu bearbeiten war als C.
Jules
1

Es könnte Sie interessieren, warum sich das GNOME-Desktop-Projekt für git anstelle von hg und bzr entschieden hat, als es sich vor einigen Jahren entschied, von svn zu wechseln. Es gab natürlich viele hitzige religiöse Diskussionen auf dem Weg, aber diese GNOME-Wiki-Seite fasst die Vor- und Nachteile der jeweiligen Community gut zusammen.

calum_b
quelle
0

Ganz zu schweigen davon, dass Apple nun daran beteiligt ist, es an die Ziel-c-Community weiterzugeben. Wenn Sie kürzlich eine neue Anwendung in Xcode 4 erstellt haben, werden Sie automatisch gefragt, ob Sie ein Git-Repo erstellen möchten.

Zugegeben, Xcode 4 gibt es erst seit ein paar Monaten und hat keinen Einfluss auf Gits früheren Erfolg, aber wir alle wissen, wie beliebt Apple Dinge in kurzer Zeit machen kann.

Tutts
quelle
-1

Ich wechsle gerade von hg (Brennofen) zu git (Github). Ich benutze den Ofen gerade seit ungefähr einem Jahr. Für mich hat hg keinen Nachteil. Ich kann alles tun, was ich muss. Es ist also großartig.

Warum verwende ich gerade jetzt?

Im Moment gibt es nur drei Gründe.

  1. gitHub bietet tolle Ideen
  2. gitHub bietet großartige soziale Funktionen
  3. Während Entwicklerpräsentationen und Workshops habe ich meine Samples immer auf hg und git veröffentlicht. Am git habe ich ca. 10 mal mehr Besucher als am hg !!

Ich denke, der dritte ist der wichtigste.

Thorsten

Thorsten
quelle
-2

Reines Glück, denke ich, bis jetzt ist es fast unmöglich zu beweisen, warum etwas funktioniert hat und andere nicht. Linus kann noch etwas Spektakuläres bauen und hat keinen Erfolg.

Acaz
quelle