Evidência empírica da popularidade de Git e Mercurial


37

É 2012! Mercurial e Git ainda são fortes.

Eu entendo os trade-offs de ambos. Eu também entendo que todo mundo tem algum tipo de preferência por um ou outro. Isso é bom.

Estou procurando algumas informações sobre o nível de uso de ambos. Por exemplo, no stackoverflow.com , pesquisar Git recebe 12.000 hits, Mercurial recebe 3000. O Google Trends diz que é 1,9: 1,0 para Git.

Que outra informação empírica está disponível para estimar o uso relativo de ambas as ferramentas?


65
Acertos do Stackoverflow podem indicar "dificuldade", não "popularidade".

6
O Git vence nas tendências do google, o github vence o bitbucket, MAS - muitas empresas comerciais preferem o Mercurial ao Git, por isso é bem possível que, embora o Git tenha mais pessoas usando, o Hg tenha mais dinheiro apostado.
c69 6/01/12

Por que as empresas preferem o Mercurial ao Git?
ana

11
Razões como essas eu suponho: stackoverflow.com/a/892688/224087 ou ericsink.com/entries/hg_denzel.html ou stevelosh.com/blog/2010/01/… Eu também acho que o Mercurial é mais polido e mais fácil de abordar. A qualidade da ferramenta também é um fator. A experiência do Mercurial é claramente melhor que a do Git no Windows. Além disso, usamos o FogBugz e o Kiln, que são um ótimo pacote integrado de controle de erros / tarefas e controle de código-fonte. Para código pessoal, bitbucket teve um melhor preço (eu poderia fugir com plano gratuito, onde eu não podia no github)
Quentin-starin

11
@ ThorbjørnRavnAndersen Concordo totalmente. Acho que o git tem uma curva de aprendizado bastante grande, onde o mercurial parece ter uma curva menos acentuada. É difícil julgar algo sobre as métricas dos hits ... Quem sabe. Talvez a ferramenta mais popular é o de menor sucesso porque ninguém precisa pedir ajuda :)
Rig

Respostas:


19

Ohloh

Em um estilo semelhante à minha resposta Git vs. SVN , Ohloh foi rastreado (apenas) três vezes pela Wayback Machine do Internet Archive , mas julho de 2011 é ilegível:

Agosto de 2010

  • Git: 26.485 repositórios (11,3% do total)
  • Mercurial: 2.548 repositórios (1,1% do total)
  • Relação: 10.4: 1.0

Maio de 2011

  • Git: 116.224 repositórios (35,3% do total)
  • Mercurial: 3.753 repositórios (1,1% do total)
  • Proporção: 31.0: 1.0

Fevereiro 2012

  • Git: 124.000 repositórios (26% do total)
  • Mercurial:?

Junho 2012

  • Git: 134.459 repositórios (27% do total)
  • Mercurial: 11.238 repositórios (2% do total)
  • Relação: 12.0: 1.0

outubro 2013

  • Git: 238.648 repositórios (38% do total)
  • Mercurial: 17.145 repositórios (2% do total)
  • Proporção: 13.9: 1.0

Abril 2014

  • Git: 238.648 repositórios (38% do total)
  • Mercurial: 17.628 repositórios (2% do total)
  • Relação: 13.5: 1.0

Pesquisa da comunidade Eclipse

Outra fonte de dados é o Eclipse Community Survey. Os valores Git abaixo são para Git / GitHub.

2009 ( pdf )

  • Git: 2.4%
  • Mercurial: 1,1% (Nota: Hg listado em "outros" no relatório de 2009, mas discriminado no relatório de 2010)
  • Relação: 2.2: 1.0

2010 ( pdf )

  • Git: 6,8%
  • Mercurial: 3%
  • Relação: 2.3: 1.0

2011 ( pdf )

  • Git: 12,8%
  • Mercurial: 1,1%
  • Relação: 11.6: 1.0

2012

  • Git: 27.6%
  • Mercurial: 2,6%
  • Relação: 10.6: 1.0

2013

  • Git: 30.3%
  • Mercurial: 3,6%
  • Relação: = 8.4: 1.0

2014

  • Git: 33.3%
  • Mercurial: 2,1%
  • Proporção: = 15,9: 1,0

Sumário

Eles parecem mostrar que, dos repositórios de código aberto registrados em Ohloh e dos desenvolvedores que usam Eclipse, o Git é uma boa ordem de magnitude mais popular que o Mercurial.


8

Acho que, além das tendências do Google ou das perguntas do SO (que, como os comentários acima apontam, podem indicar curiosidade ou dificuldade, e não uso), sua melhor aposta é analisar as estatísticas onde elas estão disponíveis e ponderá-las por fonte (como você faz isso é provavelmente sugestivo).

Você pode ver o distribuição de TODOS os sistemas de controle de versão em projetos indexados com Ohloh .

O Concurso de Popularidade Debian mostra um gráfico para estatísticas de pacotes DVCS .

E está um pouco desatualizado, mas o Resultados da Pesquisa GNOME DVCS são interessantes.

Quando se trata de números, eu acho que Ohloh é a audiência mais geral, então eu diria isso pessoalmente ... ainda muitas pessoas usando SVN e até CVS.

Em termos de software de código aberto, onde as questões importantes estão coordenando equipes amplamente distribuídas e assíncronas, o Git é o vencedor. Especialmente quando você olha a comparação da Wikipedia pela popularidade dos sites de hospedagem de projetos de código-fonte aberto (com base no número de GitHub (git) vs. BitBucket (Hg)).


8
Não que eu ache que você deva escolher um DVCS com base na popularidade.
Jason Lewis

3
Na verdade, acho que a popularidade é um excelente motivo para escolher um sistema de controle de versão devido à natureza distribuída da ferramenta. Os efeitos de externalidade da rede dão à ferramenta mais popular muito mais valor se você planeja contribuir com projetos com outros participantes.
Ana

Concordo em projetos de código aberto. Se você deseja que seu DVCS primário seja conhecido pelo maior número de colaboradores em potencial, o Git é a escolha de fato. Interno para uma organização ... você precisa ir com fatores como o tamanho de sua equipe, apoio institucional, etc.
Jason Lewis

6
Como sugeri aqui : "Você deve usar gitquando um projeto ou comunidade que você deseja contribuir para usos gite usar Mercurial quando eles usam Mercurial Pode parecer óbvio, mas a comunidade é mais importante que a ferramenta.".
Mark Booth

11
Nem tudo é técnico - considere que uma empresa precisa recrutar novos programadores para a equipe para apoiar o crescimento e a substituição. A escolha de ferramentas (DVCS é apenas uma das muitas) conhecidas significa que é mais provável que um novo recruta esteja familiarizado com ela. Além disso, uma ferramenta mais popular (particularmente o OSS) provavelmente obterá mais recursos e esforços e, com o tempo, melhorará mais rapidamente.
mattnz
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.