Evidenza empirica della popolarità di Git e Mercurial


37

È il 2012! Mercurial e Git sono entrambi ancora forti.

Comprendo i compromessi di entrambi. Capisco anche che ognuno abbia una sorta di preferenza per l'uno o l'altro. Va bene.

Sto cercando alcune informazioni sul livello di utilizzo di entrambi. Ad esempio, su stackoverflow.com , la ricerca di Git ti dà 12000 risultati, Mercurial ti ottiene 3000. Google Trends afferma che è Git 1.9: 1.0.

Quali altre informazioni empiriche sono disponibili per stimare l'utilizzo relativo di entrambi gli strumenti?


65
I risultati di StackOverflow possono indicare "difficoltà", non "popolarità".

6
Git vince nelle tendenze di google, github vince su bitbucket, MA - molte aziende commerciali preferiscono Mercurial a Git, quindi è del tutto possibile che mentre Git ha più persone che lo usano, Hg ha più scommesse su cui scommettere.
c69,

Qual è il motivo per cui le aziende preferiscono Mercurial rispetto a Git?
Ana

11
Ragioni come questi vorrei supporre: stackoverflow.com/a/892688/224087 o ericsink.com/entries/hg_denzel.html o stevelosh.com/blog/2010/01/... troppo penso Mercurial è più lucido e più facile da approccio. Anche la qualità dell'utensile è un fattore. L'esperienza Mercurial è chiaramente migliore di quella di Git su Windows. Inoltre, utilizziamo FogBugz e Kiln, che rendono un ottimo tracker di bug / task integrato e un pacchetto di controllo del codice sorgente. Per quanto riguarda il codice personale, bitbucket ha prezzi migliori (potrei cavarmela con un piano gratuito, dove non potrei farlo su Github)
Quentin-starin

1
@ ThorbjørnRavnAndersen Totalmente d'accordo. Trovo che Git abbia abbastanza la curva di apprendimento dove Mercurial sembra avere una curva meno ripida. È difficile giudicare qualcosa sulla metrica dei successi ... Chi lo sa. Forse lo strumento più popolare è quello con i risultati più bassi perché nessuno ha bisogno di chiedere aiuto :)
Rig

Risposte:


19

Ohloh

In uno stile simile alla mia risposta Git vs. SVN , Ohloh è stato sottoposto a scansione (solo) tre volte dalla Wayback Machine di Internet Archive , ma luglio 2011 è illeggibile:

Agosto 2010

  • Git: 26.485 repository (11,3% del totale)
  • Mercurial: 2.548 repository (1,1% del totale)
  • Rapporto: 10.4: 1.0

Maggio 2011

  • Git: 116.224 repository (35,3% del totale)
  • Mercurial: 3.753 repository (1,1% del totale)
  • Rapporto: 31.0: 1.0

Febbraio 2012

  • Git: 124.000 repository (26% del totale)
  • Mercuriale:?

Giugno 2012

  • Git: 134.459 repository (27% del totale)
  • Mercurial: 11.238 repository (2% del totale)
  • Rapporto: 12,0: 1,0

Ottobre 2013

  • Git: 238.648 repository (38% del totale)
  • Mercurial: 17.145 repository (2% del totale)
  • Rapporto: 13,9: 1,0

Aprile 2014

  • Git: 238.648 repository (38% del totale)
  • Mercurial: 17.628 repository (2% del totale)
  • Rapporto: 13,5: 1,0

Sondaggio della community Eclipse

Un'altra fonte di dati è l'Eclipse Community Survey. I valori Git di seguito sono per Git / GitHub.

2009 ( pdf )

  • Git: 2,4%
  • Mercuriale: 1,1% (Nota: Hg elencato sotto "altro" nel rapporto 2009, ma dettagliato nel rapporto 2010)
  • Rapporto: 2.2: 1.0

2010 ( pdf )

  • Git: 6,8%
  • Mercuriale: 3%
  • Rapporto: 2.3: 1.0

2011 ( pdf )

  • Git: 12,8%
  • Mercuriale: 1,1%
  • Rapporto: 11.6: 1.0

2012

  • Git: 27,6%
  • Mercuriale: 2,6%
  • Rapporto: 10.6: 1.0

2013

  • Git: 30,3%
  • Mercuriale: 3,6%
  • Rapporto: = 8.4: 1.0

2014

  • Git: 33,3%
  • Mercuriale: 2,1%
  • Rapporto: = 15.9: 1.0

Sommario

Questi sembrano mostrare che, dei repository open source registrati su Ohloh e degli sviluppatori che usano Eclipse, Git è un buon ordine di grandezza più popolare di Mercurial.


8

Penso che a parte le tendenze di Google o le domande SO (che, come sottolineano i commenti sopra, potrebbero indicare curiosità o difficoltà piuttosto che utilizzo), la soluzione migliore è guardare le statistiche dove sono disponibili e ponderarle per fonte (come fai questo è probabilmente suggestivo, però).

Puoi vedere la distribuzione di TUTTI i sistemi di controllo versione su progetti indicizzati con Ohloh .

Il concorso di popolarità Debian mostra un grafico delle statistiche per i pacchetti DVCS .

Ed è un po 'datato, ma i risultati del sondaggio GNOME DVCS sono interessanti.

Quando si tratta di numeri, penso che Ohloh sia il pubblico più generale, quindi andrei con quello, personalmente ... comunque MOLTE persone che usano SVN e persino CVS, però.

In termini di software open source, in cui le questioni importanti stanno coordinando team ampiamente distribuiti e asincroni, Git è il vincitore senza dubbio. Soprattutto quando si osserva il confronto di Wikipedia in base alla popolarità dei siti di hosting di progetti open source (in base al numero di GitHub (git) vs. BitBucket (Hg)).


8
Non che penso che dovresti scegliere un DVCS basato sulla popolarità.
Jason Lewis

3
In realtà, penso che la popolarità sia un ottimo motivo per scegliere un sistema di controllo della versione a causa della natura distribuita dello strumento. Gli effetti di esternalità della rete danno allo strumento più popolare un valore decisamente maggiore se prevedi di contribuire a progetti con altri partecipanti.
Ana

Sono d'accordo per progetti open source. Se vuoi che il tuo DVCS primario sia noto al maggior numero di potenziali collaboratori, Git è di fatto la scelta. Interno di un'organizzazione ... devi andare con fattori come le dimensioni della tua squadra, il supporto istituzionale, ecc.
Jason Lewis

6
Come ho suggerito qui : "Dovresti usare gitquando un progetto o una comunità vuoi contribuire agli usi gite usare Mercurial quando usano Mercurial. Può sembrare ovvio, ma la comunità è più importante dello strumento."
Mark Booth,

1
Non è tutto tecnico: considera che un'azienda deve reclutare nuovi programmatori nel team per supportare la crescita e la sostituzione. Scegliere strumenti (DVCS è solo uno dei tanti) che sono ben noti significa che è più probabile che una nuova recluta ne abbia familiarità. Anche uno strumento più popolare (in particolare OSS) probabilmente otterrà più risorse e sforzi e nel tempo migliorerà più rapidamente.
mattnz,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.