Evidencia empírica de popularidad de Git y Mercurial


37

¡Es 2012! Mercurial y Git siguen siendo fuertes.

Entiendo las compensaciones de ambos. También entiendo que todos tienen algún tipo de preferencia por uno u otro. Esta bien.

Estoy buscando información sobre el nivel de uso de ambos. Por ejemplo, en stackoverflow.com , la búsqueda de Git te da 12000 visitas, Mercurial te da 3000. Google Trends dice que es 1.9: 1.0 para Git.

¿Qué otra información empírica está disponible para estimar el uso relativo de ambas herramientas?


65
Los éxitos de Stackoverflow pueden indicar "dificultad", no "popularidad".

66
Git gana en las tendencias de Google, Github gana sobre Bitbucket, PERO, afaik muchas empresas comerciales prefieren Mercurial sobre Git, por lo que es muy posible que mientras Git tenga más gente usándolo, Hg tenga más dinero apostado.
c69

¿Por qué las empresas prefieren Mercurial a Git?
ana

11
Razones como estas, supongo: stackoverflow.com/a/892688/224087 o ericsink.com/entries/hg_denzel.html o stevelosh.com/blog/2010/01/… También creo que Mercurial es más pulido y más fácil de abordar. La calidad de la herramienta también es un factor. La experiencia Mercurial es claramente mejor que la de Git en Windows. Además, utilizamos FogBugz y Kiln, que son un muy buen rastreador de errores / tareas integrado y un paquete de control de código fuente. Para el código personal, Bitbucket tenía mejores precios (podía salirse con la suya con un plan gratuito, donde no podía con github)
quentin-starin

1
@ ThorbjørnRavnAndersen Totalmente de acuerdo. Encuentro que git tiene bastante la curva de aprendizaje donde mercurial parece tener una curva menos empinada. Es difícil juzgar algo sobre la métrica de los golpes ... Quién sabe. Quizás la herramienta más popular es la que tiene los resultados más bajos porque nadie necesita pedir ayuda :)
Rig

Respuestas:


19

Ohloh

En un estilo similar a mi respuesta Git vs. SVN , Ohloh ha sido rastreada (solo) tres veces por la máquina Wayback de Internet Archive , pero julio de 2011 es ilegible:

Agosto 2010

  • Git: 26,485 repositorios (11.3% del total)
  • Mercurial: 2.548 repositorios (1.1% del total)
  • Ratio: 10.4: 1.0

Mayo de 2011

  • Git: 116,224 repositorios (35.3% del total)
  • Mercurial: 3.753 repositorios (1.1% del total)
  • Ratio: 31.0: 1.0

Febrero de 2012

  • Git: 124,000 repositorios (26% del total)
  • Mercurial:?

junio 2012

  • Git: 134,459 repositorios (27% del total)
  • Mercurial: 11,238 repositorios (2% del total)
  • Ratio: 12.0: 1.0

octubre 2013

  • Git: 238,648 repositorios (38% del total)
  • Mercurial: 17.145 repositorios (2% del total)
  • Ratio: 13.9: 1.0

Abril 2014

  • Git: 238,648 repositorios (38% del total)
  • Mercurial: 17,628 repositorios (2% del total)
  • Ratio: 13.5: 1.0

Encuesta comunitaria de Eclipse

Otra fuente de datos es la Eclipse Community Survey. Los valores de Git a continuación son para Git / GitHub.

2009 ( pdf )

  • Git: 2.4%
  • Mercurial: 1.1% (Nota: Hg listado en "otro" en el informe de 2009, pero detallado en el informe de 2010)
  • Relación: 2.2: 1.0

2010 ( pdf )

  • Git: 6.8%
  • Mercurial: 3%
  • Ratio: 2.3: 1.0

2011 ( pdf )

  • Git: 12.8%
  • Mercurial: 1.1%
  • Ratio: 11.6: 1.0

2012

  • Git: 27,6%
  • Mercurial: 2.6%
  • Ratio: 10.6: 1.0

2013

  • Git: 30,3%
  • Mercurial: 3.6%
  • Ratio: = 8.4: 1.0

2014

  • Git: 33,3%
  • Mercurial: 2.1%
  • Ratio: = 15.9: 1.0

Resumen

Esto parece mostrar que, de los repositorios de código abierto registrados en Ohloh, y de los desarrolladores que usan Eclipse, Git es un buen orden de magnitud más popular que Mercurial.


8

Creo que, aparte de las tendencias de Google o las preguntas SO (que, como señalan los comentarios anteriores, podrían indicar curiosidad o dificultad en lugar de uso), su mejor opción es mirar las estadísticas donde están disponibles y ponderarlas por fuente (cómo lo hace eso es probablemente sugerente, sin embargo).

Puede ver la distribución de TODOS los sistemas de control de versiones en proyectos indexados con Ohloh .

El concurso de popularidad de Debian muestra un gráfico de estadísticas para paquetes DVCS .

Y está un poco desactualizado, pero los resultados de la encuesta GNOME DVCS son interesantes.

En lo que respecta a los números, creo que Ohloh es la audiencia más general, así que iría con eso, personalmente ... todavía hay MUCHAS personas que usan SVN e incluso CVS.

En términos de software de código abierto, donde los problemas importantes son la coordinación de equipos ampliamente distribuidos y asincrónicos, Git es el ganador indiscutible. Especialmente cuando observa la comparación de Wikipedia por popularidad de los sitios de alojamiento de proyectos de código abierto (en función de los números de GitHub (git) frente a BitBucket (Hg)).


8
No es que piense que debería elegir un DVCS basado en popularidad.
Jason Lewis

3
En realidad, creo que la popularidad es una excelente razón para elegir un sistema de control de versiones debido a la naturaleza distribuida de la herramienta. Los efectos de externalidad de red le dan a la herramienta más popular mucho más valor si planea contribuir a proyectos con otros participantes.
Ana

Estoy de acuerdo con los proyectos de código abierto. Si desea que su DVCS primario sea conocido por la mayor cantidad de contribuyentes potenciales, Git es la opción de facto. Interno a una organización ... tienes que ir con factores tales como el tamaño de su equipo, el apoyo institucional, etc.
Jason Lewis

66
Como sugerí aquí : "Debería usar gitcuando un proyecto o comunidad que desea contribuir utiliza git, y usar Mercurial cuando usan Mercurial. Puede parecer obvio, pero la comunidad es más importante que la herramienta".
Mark Booth

1
No todo es técnico: considere que una empresa necesita reclutar nuevos programadores para el equipo para apoyar el crecimiento y el reemplazo. Elegir herramientas (DVCS es solo una de muchas) que son bien conocidas significa que es más probable que un nuevo recluta esté familiarizado con él. Además, una herramienta más popular (particularmente OSS) probablemente obtendrá más recursos y esfuerzo y con el tiempo mejorará más rápido.
mattnz
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.