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.