Empirische Belege für die Popularität von Git und Mercurial

37

Es ist 2012! Mercurial und Git sind beide noch stark.

Ich verstehe die Kompromisse von beiden. Ich verstehe auch, dass jeder eine Vorliebe für das eine oder andere hat. Das ist gut.

Ich suche nach Informationen zum Nutzungsgrad von beiden. Wenn Sie zum Beispiel auf stackoverflow.com nach Git suchen, erhalten Sie 12000 Treffer, Mercurial 3000. Laut Google Trends ist es 1,9: 1,0 für Git.

Welche weiteren empirischen Informationen stehen zur Verfügung, um die relative Verwendung beider Tools abzuschätzen?

git mercurial ana
quelle
65
Stackoverflow-Treffer können auf "Schwierigkeit" hindeuten, nicht auf "Beliebtheit".
6
Git gewinnt in Google-Trends, Github gewinnt über Bitbucket, ABER - viele kommerzielle Unternehmen bevorzugen Mercurial gegenüber Git, so dass es durchaus möglich ist, dass Git zwar mehr Nutzer hat, Hg jedoch mehr Geldeinsatz hat.
06.01.12
Was ist der Grund, warum Unternehmen Mercurial Git vorziehen?
Ana
11
Gründe wie diese würde ich annehmen: stackoverflow.com/a/892688/224087 oder ericsink.com/entries/hg_denzel.html oder stevelosh.com/blog/2010/01/… Ich denke auch, dass Mercurial ausgefeilter und einfacher zu erreichen ist. Auch die Werkzeugqualität spielt eine Rolle. Die Mercurial-Erfahrung ist deutlich besser als die von Git unter Windows. Außerdem verwenden wir FogBugz und Kiln, die ein sehr schönes, integriertes Paket aus Bug- / Task-Tracker und Quellcode-Kontrolle darstellen. Für persönlichen Code hatte Bitbucket bessere Preise (ich konnte mit freiem Plan davonkommen, wo ich nicht auf Github konnte)
Quentin-Starin
1
@ ThorbjørnRavnAndersen Stimme voll und ganz zu. Ich finde git, um ziemlich die Lernkurve zu haben, wo mercurial scheint, eine weniger steile Kurve zu haben. Es ist schwer, etwas an den Metriken der Treffer zu messen ... Wer weiß. Vielleicht ist das beliebteste Tool das mit den niedrigsten Treffern, weil niemand um Hilfe bitten muss :)
Rig

Antworten:

19

Ohloh

In einem ähnlichen Stil zu meinem Git vs. SVN Antwort , Ohloo gecrawlt (nur) drei Mal durch die Wayback Machine Internet Archive , aber Juli 2011 ist nicht lesbar:

August 2010

  • Git: 26.485 Repositories (11,3% der Gesamtzahl)
  • Mercurial: 2.548 Repositories (1,1% der Gesamtmenge)
  • Verhältnis: 10,4: 1,0

Mai 2011

  • Git: 116.224 Repositories (35,3% der Gesamtzahl)
  • Mercurial: 3.753 Repositories (1,1% der Gesamtmenge)
  • Verhältnis: 31,0: 1,0

Februar 2012

  • Git: 124.000 Repositories (26% der Gesamtzahl)
  • Mercurial:?

Juni 2012

  • Git: 134.459 Repositories (27% der Gesamtzahl)
  • Mercurial: 11.238 Repositories (2% der Gesamtzahl)
  • Verhältnis: 12,0: 1,0

Oktober 2013

  • Git: 238.648 Repositories (38% der Gesamtzahl)
  • Mercurial: 17.145 Repositories (2% der Gesamtzahl)
  • Verhältnis: 13,9: 1,0

April 2014

  • Git: 238.648 Repositories (38% der Gesamtzahl)
  • Mercurial: 17.628 Repositories (2% der Gesamtzahl)
  • Verhältnis: 13,5: 1,0

Eclipse-Community-Umfrage

Eine weitere Datenquelle ist die Eclipse Community Survey. Die folgenden Git-Werte gelten für Git / GitHub.

2009 ( pdf )

  • Git: 2,4%
  • Mercurial: 1,1% (Anmerkung: Hg im Bericht 2009 unter "Sonstige" aufgeführt, im Bericht 2010 jedoch aufgeschlüsselt)
  • Verhältnis: 2,2: 1,0

2010 ( pdf )

  • Git: 6,8%
  • Mercurial: 3%
  • Verhältnis: 2,3: 1,0

2011 ( pdf )

  • Git: 12,8%
  • Mercurial: 1,1%
  • Verhältnis: 11,6: 1,0

2012

  • Git: 27,6%
  • Mercurial: 2,6%
  • Verhältnis: 10,6: 1,0

2013

  • Git: 30,3%
  • Mercurial: 3,6%
  • Verhältnis: = 8,4: 1,0

2014

  • Git: 33,3%
  • Mercurial: 2,1%
  • Verhältnis: = 15,9: 1,0

Zusammenfassung

Dies scheint zu zeigen, dass Git unter den auf Ohloh registrierten Open-Source-Repositorys und unter den Entwicklern, die Eclipse verwenden, eine gute Größenordnung populärer ist als Mercurial.

Hugo
quelle
8

Ich denke, anders als bei Google-Trends oder SO-Fragen (die, wie die obigen Kommentare zeigen, eher auf Neugierde oder Schwierigkeit hinweisen als auf Nutzung), ist es am besten, Statistiken zu betrachten, wo sie verfügbar sind, und sie nach Quelle zu gewichten (wie Sie es tun) das ist aber wahrscheinlich suggestiv).

Sie können die Verteilung von ALLEN Versionskontrollsystemen auf mit Ohloh indizierte Projekte sehen .

Der Debian-Beliebtheitswettbewerb zeigt eine Grafik für Statistiken für DVCS-Pakete .

Und es ist ein bisschen veraltet, aber die Ergebnisse der GNOME DVCS-Umfrage sind interessant.

Wenn es um die Zahlen geht, denke ich, dass Ohloh das allgemeinste Publikum ist, also würde ich persönlich damit weitermachen ... immer noch eine Menge Leute, die SVN und sogar CVS verwenden.

In Bezug auf Open-Source-Software, bei der die Koordinierung von breit verteilten und asynchronen Teams von entscheidender Bedeutung ist, ist Git zweifelsohne der Gewinner. Besonders wenn man den Vergleich von Wikipedia nach Beliebtheit von Open-Source-Projekt-Hosting-Sites betrachtet (basierend auf der Anzahl von GitHub (git) vs. BitBucket (Hg)).

Jason Lewis
quelle
8
Nicht, dass ich denke, dass Sie ein DVCS basierend auf der Popularität wählen sollten.
Jason Lewis
3
Tatsächlich denke ich, dass Popularität ein hervorragender Grund ist, sich für ein Versionskontrollsystem zu entscheiden, da das Tool verteilt ist. Die Netzwerkexternalitätseffekte verleihen dem beliebten Tool einen erheblich höheren Wert, wenn Sie planen, einen Beitrag zu Projekten mit anderen Teilnehmern zu leisten.
Ana
Ich bin einverstanden mit Open Source Projekten. Wenn Sie möchten, dass Ihr primäres DVCS den meisten potenziellen Mitwirkenden bekannt ist, ist Git de facto die erste Wahl. Organisationsintern ... müssen Sie Faktoren wie die Größe Ihres Teams, die institutionelle Unterstützung usw. berücksichtigen.
Jason Lewis
6
Wie ich hier vorschlug : "Sie sollten verwenden, gitwenn ein Projekt oder eine Community verwendet werden soll, für die Sie einen Beitrag leisten möchtengit , und Mercurial verwenden , wenn sie Mercurial verwenden. Es mag offensichtlich erscheinen, aber die Community ist wichtiger als das Tool."
Mark Booth
1
Es ist nicht alles technisch - bedenken Sie, dass ein Unternehmen neue Programmierer im Team einstellen muss, um Wachstum und Ersatz zu unterstützen. Die Auswahl von Tools (DVCS ist nur eines von vielen), die bekannt sind, bedeutet, dass ein neuer Mitarbeiter eher mit dem Tool vertraut ist. Auch ein beliebteres Tool (insbesondere OSS) wird wahrscheinlich mehr Ressourcen und Aufwand benötigen und sich mit der Zeit schneller verbessern.
Mattnz