Empiryczne dowody popularności Git i Mercurial


37

To 2012 rok! Mercurial i Git są nadal silne.

Rozumiem kompromisy obu. Rozumiem również, że każdy ma jakieś preferencje dla jednego lub drugiego. W porządku.

Szukam informacji o poziomie wykorzystania obu. Na przykład na stackoverflow.com wyszukiwanie Git daje 12000 trafień, Mercurial - 3000. Google Trends mówi, że Git to 1,9: 1,0.

Jakie inne informacje empiryczne są dostępne, aby oszacować względne użycie obu narzędzi?


65
Trafienia nakładania stosu mogą oznaczać „trudność”, a nie „popularność”.

6
Git wygrywa w trendach Google, github wygrywa z bitbucket, ALE - afaik wiele firm komercyjnych woli Mercurial niż Git, więc jest całkiem możliwe, że podczas gdy Git ma więcej osób korzystających z niego, Hg ma więcej pieniędzy na zakłady.
c69

Jaki jest powód, dla którego firmy wolą Mercurial od Git?
ana

11
Przypuszczam, że powody takie jak: stackoverflow.com/a/892688/224087 lub ericsink.com/entries/hg_denzel.html lub stevelosh.com/blog/2010/01/... Ja też uważam, że Mercurial jest bardziej dopracowany i łatwiejszy do osiągnięcia. Jakość narzędzia jest również ważnym czynnikiem. Doświadczenie Mercurial jest wyraźnie lepsze niż Git w systemie Windows. Ponadto używamy FogBugz i Kiln, które tworzą bardzo ładny zintegrowany moduł śledzenia błędów / zadań i pakiet kontroli kodu źródłowego. W przypadku kodu osobistego bitbucket miał lepszą cenę (mogłem uciec z darmowego planu, gdzie nie mogłem na github)
quentin-starin

1
@ ThorbjørnRavnAndersen Całkowicie się zgadzam. Uważam, że git ma dość krzywą uczenia się, w której merkurial wydaje się mieć mniej stromą krzywą. Trudno ocenić coś na podstawie trafień ... Kto wie. Być może najpopularniejszym narzędziem jest to, które ma najniższe trafienia, ponieważ nikt nie musi prosić o pomoc :)
Rig

Odpowiedzi:


19

Ohloh

W podobnym stylu do mojego Git vs. SVN odpowiedź , Ohloh zostały zaindeksowane (tylko) trzy razy przez Internet Archive Wayback w Maszynie , ale lipcu 2011 jest nieczytelny:

Sierpień 2010 r

  • Git: 26 485 repozytoriów (11,3% całości)
  • Mercurial: 2548 repozytoriów (1,1% całości)
  • Stosunek: 10,4: 1,0

Maj 2011 r

  • Git: 116 224 repozytoria (35,3% całości)
  • Mercurial: 3 753 repozytoria (1,1% całości)
  • Stosunek: 31,0: 1,0

Luty 2012 r

  • Git: 124 000 repozytoriów (26% całości)
  • Rtęciowe:?

Czerwiec 2012 r

  • Git: 134.459 repozytoriów (27% całości)
  • Mercurial: 11.238 repozytoriów (2% całości)
  • Stosunek: 12,0: 1,0

Październik 2013

  • Git: 238,648 repozytoriów (38% całości)
  • Mercurial: 17 145 repozytoriów (2% całości)
  • Stosunek: 13,9: 1,0

Kwiecień 2014 r

  • Git: 238,648 repozytoriów (38% całości)
  • Mercurial: 17 628 repozytoriów (2% całości)
  • Stosunek: 13,5: 1,0

Ankieta społeczności Eclipse

Innym źródłem danych jest Eclipse Community Survey. Wartości Git poniżej dotyczą Git / GitHub.

2009 ( pdf )

  • Git: 2,4%
  • Rtęciowe: 1,1% (Uwaga: Hg wymienione w części „inne” w raporcie z 2009 r., Ale wyszczególnione w raporcie z 2010 r.)
  • Stosunek: 2,2: 1,0

2010 ( pdf )

  • Git: 6,8%
  • Rtęciowe: 3%
  • Stosunek: 2,3: 1,0

2011 ( pdf )

  • Git: 12,8%
  • Rtęciowe: 1,1%
  • Stosunek: 11,6: 1,0

2012

  • Git: 27,6%
  • Rtęciowe: 2,6%
  • Stosunek: 10,6: 1,0

2013

  • Git: 30,3%
  • Rtęciowe: 3,6%
  • Stosunek: = 8,4: 1,0

2014

  • Git: 33,3%
  • Rtęciowe: 2,1%
  • Stosunek: = 15,9: 1,0

Podsumowanie

Wydaje się, że pokazują, że spośród repozytoriów open source zarejestrowanych na Ohloh i programistów używających Eclipse, Git jest o rząd wielkości większy niż popularność Mercurial.


8

Myślę, że poza trendami Google lub pytaniami SO (które, jak wskazują powyższe komentarze, mogą wskazywać na ciekawość lub trudność, a nie użycie), najlepiej jest spojrzeć na statystyki tam, gdzie są one dostępne, i ocenić je według źródła (jak to robisz to jednak może sugerować).

Możesz zobaczyć dystrybucję WSZYSTKICH systemów kontroli wersji w projektach indeksowanych za pomocą Ohloh .

Konkurs popularności Debiana pokazuje wykres statystyk dla pakietów DVCS .

To trochę przestarzałe, ale wyniki ankiety GNOME DVCS są interesujące.

Jeśli chodzi o liczby, myślę, że Ohloh jest najbardziej ogólną publicznością, więc chciałbym pójść z tym, osobiście ... wciąż dużo ludzi używa SVN, a nawet CVS.

Jeśli chodzi o oprogramowanie typu open source, w którym istotnymi zagadnieniami są koordynacje szeroko rozproszonych i asynchronicznych zespołów, Git jest bezkonkurencyjnym zwycięzcą. Zwłaszcza, gdy spojrzysz na porównanie Wikipedii według popularności witryn hostingowych projektów open source (na podstawie liczby GitHub (git) vs. BitBucket (Hg)).


8
Nie sądzę, że powinieneś wybrać DVCS na podstawie popularności.
Jason Lewis,

3
Właściwie uważam, że popularność jest doskonałym powodem wyboru systemu kontroli wersji ze względu na rozproszony charakter tego narzędzia. Efekty zewnętrzne sieci dają bardziej popularne narzędzie o wiele większej wartości, jeśli planujesz uczestniczyć w projektach z innymi uczestnikami.
Ana

Zgadzam się na projekty typu open source. Jeśli chcesz, aby Twój główny DVCS był znany jak największej liczbie potencjalnych współpracowników, Git jest de facto wyborem. Wewnątrz organizacji ... musisz iść z czynnikami, takimi jak wielkość zespołu, wsparcie instytucjonalne itp.
Jason Lewis

6
Jak zasugerowałem tutaj : „Powinieneś użyć, gitgdy projekt lub społeczność chcesz przyczynić się do wykorzystania git, i użyć Mercurial, gdy używają Mercurial. Może to wydawać się oczywiste, ale społeczność jest ważniejsza niż narzędzie”.
Mark Booth

1
To nie wszystko techniczne - weź pod uwagę, że firma musi rekrutować nowych programistów do zespołu, aby wspierać rozwój i wymianę. Wybór narzędzi (DVCS jest tylko jednym z wielu), które są dobrze znane, oznacza, że ​​nowy rekrut bardziej chętnie się z nim zapozna. Również bardziej popularne narzędzie (szczególnie OSS) prawdopodobnie zyska więcej zasobów i wysiłku, a wraz z upływem czasu poprawi się szybciej.
mattnz
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.