Por que o aumento repentino no número de remetentes do Git no gráfico popcon do Debian em 2010-01?


86

Quase todos os artigos que li 1 comparando Git e Mercurial parecem que o Mercurial tem uma melhor linha de comando UX, com cada comando sendo limitado a apenas uma idéia (ao contrário do que diz git checkout).

Mas, em algum momento, o Git repentinamente se tornou super popular e o número de remetentes do Git no gráfico popcon do Debian (veja a imagem abaixo) literalmente explodiu.

Git vs. Mercurial popularidade

Fonte: Debian

O que aconteceu em 2010-01 que as coisas mudaram de repente. Parece que o GitHub foi fundado antes disso - 2008.


23
bem, em algum momento o github atingiu um ponto de inflexão e decolou. Duvido que tenha sido idiota por si só. Gostaria de saber se alguém poderia correlacionar a população dos gits com a popularidade dos githubs?
Doug T.

2
Por curiosidade, o que o "número de remetentes" representa?
Adam Houldsworth

6
Você está curioso sobre a popularidade geral do Git ou a instalação do Git no Debian? Seus dados fornecem apenas informações sobre uma distribuição Linux, ignorando todas as outras distribuições Linux, juntamente com os sistemas operacionais BSD, Mac e Windows, mas você está fazendo uma pergunta genérica sobre o aumento no uso de uma ferramenta. Com base em algumas das respostas, há uma explicação específica do Debian, mas há dados insuficientes para falar sobre a popularidade do Git versus a popularidade do Mercurial entre todos os usuários em potencial. Parece que a pergunta apresentada é baseada em suposições defeituosas.
Thomas Owens

32
Git literalmente explodiu? Git não soa como uma ferramenta segura. Obrigado pelo aviso.
31512 Jason

4
Apenas um pouco, mas o git é usado em um grande número de outros pacotes. Veja a diferença entre apt-cache rdepends git-core, e apt-cache rdepends mercurial. Talvez não tenha nada a ver com o git, mas está incluído porque alguém instalou algum outro pacote comum. Por exemplo, eu sou usuário do etckeeper e do ikiwiki, ambos baseados no git (acho que pode ser possível usar também o mercurial). Sugiro que você dedique algum tempo e analise todas as várias coisas que dependem ou recomendam o git-core.
Zoredache

Respostas:


48

O pacote "gnuit" (GNU Interactive Tools, um navegador / visualizador de arquivos e visualizador de processos) foi chamado "git" no Debian até 2009-09-09, enquanto o git foi chamado "git-core".

Portanto, um gráfico melhor para analisar é:

O que mostra que a popularidade não aumentou drasticamente (pegue a linha verde da parte esquerda até cruzar e depois a linha vermelha).


17
Ainda parece que em 2010/2011, houve um aumento dramático na popularidade. Passou de cerca de 13 mil instalações do git-core (que é o Git) em 2010-01 para bem mais de 50 mil instalações (acumulativas dos pacotes git-core e git) em 2011-01. Isso representa um aumento de quase 40 mil instalações em um ano - um aumento muito mais acentuado do que qualquer outro aumento anual.
Thomas Owens

3
Alguém no HN editou a imagem e ainda parece haver um aumento dramático como o @ThomasOwens menciona. i.imgur.com/PmYj7.png
Jungle Hunter

2
Sim, ele ainda vai de crescimento linear para exponencial, o que é muito significativo, mesmo se ele não foi tão repentino quanto parece à primeira vista
Ben Brocka

3
@BenBrocka Isso não é realmente ir de linear para linear com um coeficiente mais alto? :) E provavelmente será logarítmico.
kreativitea

2
@RussellBorogove: Bobagem. O número de lhamas voadores bioluminescentes no Djibuti está aumentando exponencialmente, e espero que isso continue para sempre.
Caracol mecânico

34

O pacote git no Debian era conhecido anteriormente como git-core. Em abril de 2010, o pacote foi renomeado para git. Mais detalhes podem ser encontrados nesta postagem do blog por Julius Plenz ou neste commit no Debian .

Aqui está um gráfico que mostra o número de instalações de ambos gite ao git-corelongo do tempo:

Git-GitCore-Graph


1
Seria bom ter uma captura de tela do gráfico aqui. Se você quiser, posso adicioná-lo. :)
Caçador da selva

1
+1. Este gráfico demonstra melhor o que aconteceu com a renomeação do pacote.
Jeff Ferland

26

Eu estava usando o Darcs para meus próprios projetos por um tempo. Eu mudei para git durante a ascensão rápida a que seu gráfico se refere, então aqui está minha observação:

Os sistemas de controle de fonte distribuídos naquela época eram uma coisa de ponta. Os chamados programadores alfa os estavam usando de lado, mas ficaram fora do radar da maioria dos desenvolvedores de software profissionais. A maneira de ver o mundo no CVS / SVN / SourceSafe / TFS era algo que os programadores em geral estavam mais ou menos satisfeitos e a maioria das pessoas supunha que os problemas que geravam o sistema de controle de fonte distribuído pudessem ser corrigidos com melhores ferramentas. Assim como você obteve uma melhoria ao acessar o CVS -> SVN, um dia haveria algo que permitiria que você usasse SVN -> SVN ++. De que outra forma você gerenciaria o controle de origem?

Então veio o git. O que forçou o radar no radar de todos foi que havia um grande projeto público que o adotou imediatamente. O Git conseguiu muitos usuários de graça - se você faria um hackage sério do kernel, usou o git. Embora eu não tenha 100% de certeza, eu apostaria que naquele momento nenhum outro DVCS tinha uma base de usuários tão grande.

Então funcionou. Funcionou bem. Funcionou bem em público. Também, por suas verrugas iniciais, era mais estável do que a maioria dos DVCS simultâneos na época. Darcs, por exemplo, poderia ser colocado em um estado inconsistente que exigisse uma utilidade absurdamente complexa (quadrática? Fatorial? Não me lembro com certeza, mas era ruim ) de corrigir. O Git sempre foi mais estável.

De sua grande base de usuários, ele meio que desapareceu.

Todo projeto, comercial ou de código aberto, precisa dessa massa crítica. Darcs não entendeu. Mercurial também não. Pense de volta. Muitos projetos menores o utilizam. Provavelmente existem até vários usuários comerciais. Mas qual é a sua grande história de sucesso?

"Se é bom o suficiente para o kernel Linux, é bom o suficiente para você" é um argumento muito convincente.

Então, para resumir, foi um bom produto que surgiu no momento certo e obteve uma grande base de usuários dedicada.


4
Eu acho que o git e o hg começaram por volta de 2005, em 2010 eles tinham uma tecnologia de 5 anos. Eu não os chamaria de mainstream, mas também não acho que o sangramento esteja correto.
R0MANARMY

10
como isso responde à pergunta? "O que aconteceu em 2010-01 que as coisas mudou de repente" , como mostrado na captura de tela
mosquito

2
@gnat Esse é o estágio de massa crítica / sangramento a que eu estava me referindo.
30512 Michael

4
@ Michael, do jeito que eu vejo, sua resposta não explica muito sobre isso. Com todo o respeito, a forma como está redigida agora parece mais um palpite, um tiro no escuro. "Naquela época, janeiro 2010, eu senti como ele está vindo, havia algo no ar ..." Não muito útil desculpe
mosquito

1
As questões que gerou distribuídos de controle de origem ter sido fixada pelo melhor ferramental. O SVN de hoje é muito melhor do que a versão de anos que o pessoal do DVCS parece achar ainda atual, e corrige os problemas inerentes ao modelo antigo sem apresentar todas as novas dores de cabeça e complexidade adicional que o DVCS traz para a mesa.
Mason Wheeler

13

Eu era um adotante tardio - mudando do Mercurial para o Git por volta de 2010.

A razão pela qual acredito que o Git se tornou tão popular é por causa de sites como o GitHub que você teve um efeito de rede nas ferramentas de controle de versão. Isso não era visto anteriormente, pois você compartilhava o código em um projeto ou empresa.

Lembro-me especificamente de mudar para o Git e o Github porque todos os projetos nos quais eu estava interessado em seguir e com os quais contribuíam haviam feito o mesmo, assim como os desenvolvedores com os quais associo.

Esse é um efeito de rede.

O GitHub foi a camada de colaboração baseada na Web mais popular criada no DVCS e o Git acabou sendo 'bom o suficiente'. Mercurial era certamente mais fácil de aprender e usar, o Git tem muitas nuances, mas tinha uma marca sólida por causa de Linus.

Só porque o GitHub foi lançado em 08 e o crescimento começa em 10 não significa que o GitHub não seja responsável. Se você observar os gráficos de crescimento competitivo em outras áreas, como as redes sociais e o crescimento do Facebook, a linha é muito semelhante.

Você não vê gráficos de crescimento como esse sem um efeito de loop / rede viral.

Por exemplo. comparar com um gráfico de crescimento do Facebook

gráfico de crescimento do facebook

Atualização: Eu sei que a fonte acima pode não ter sido precisa, mas existem muitas fontes de dados que demonstram que o Git tem crescido exponencialmente nos últimos anos.

Gráfico 1: Menções ao Git nos anúncios de emprego

menção de git em anúncios de emprego

E a pesquisa Eclipse, que mostra que a participação no mercado Git passou de 13% em 2011 para 27% em 2012 . Crescimento surpreendente.

Este post oferece uma explicação muito melhor do crescimento do Git e dos efeitos de rede do que o que eu fiz aqui.


9
Há uma grande diferença entre um aumento exponencial (como vemos no gráfico do facebook) e o gráfico original que a pergunta incluía. Se esse gráfico fosse acreditado, há uma descontinuidade dramática na inclinação em um ponto específico - que implicaria algum evento que acontecesse, não um efeito de rede. E, de fato, parece de outras respostas que esse evento foi renomeado para o pacote! :)
starwed

Esse gráfico pode estar errado, mas há outras pesquisas que demonstram que o crescimento do Git tem sido exponencial. Por exemplo. A Pesquisa do Eclipse, conforme discutido neste post (que mostra o mesmo ponto que estou argumentando, mas de uma maneira muito melhor): jamesmckay.net/2012/06/…
nikcub

O link mckay está quebrado. Aqui está a versão do Wayback Machine .
Faheem Mitha

5

Apenas para esclarecer, este gráfico mostra a instalação do git nos sistemas debian.

Na época em que ocorre o pico, o pacote Debian foi renomeado de git-core para git. Talvez as pessoas tenham achado o pacote mais fácil agora que o nome refletia o software.


5

Estou surpreso que ninguém tenha mencionado o Github como uma das maiores razões para o Git ganhar popularidade . Eles empurraram o git mainstream.

O Github foi lançado em abril de 2008 e em 1-2 anos, eles ganharam popularidade. E então, quando você vê uma explosão repentina do uso do git / git-core, isso se deve principalmente aos usuários do 2Million github e a seus repositórios de 3,7 milhões. O Github tornou o git fácil de usar. O Bitbucket estava lá, mas o github tornou isso fácil. Eu tenho certeza que se os caras do github escolheram Hg no lugar do git, deveríamos ter visto o mesmo aumento no uso do Hg.

A analogia pode ser: Canonical: Linux :: Github: Git


Eu concordo absolutamente. O Github torna o controle de revisões divertido, fácil de entender e muito útil com todos esses repositórios de código aberto. Na minha opinião, eles são o motivo pelo qual o Git se tornou tão grande.
d34n5

1

Bem, o IMHO, VCs distribuídos como Hg e Git são inerentemente melhores que um VCS centralizado - então o SVN sempre perdia para um deles.

E o git, como já foi observado, teve a enorme vantagem sobre o Hg por ter sido usado pelo maior e mais bem-sucedido projeto de código-fonte aberto do planeta - é um inferno de um histórico, desde o início.

Quanto ao porquê da súbita explosão no início de 2010, meu palpite é bastante prosaico. O Git é brilhante, mas não é extremamente intuitivo para iniciantes.

O melhor livro do Git, IMHO, é o Pro Git, publicado em setembro de 2009. O segundo (IMHO novamente), o livro do O'Reilly's Git, foi publicado em junho de 2009.

Portanto, o motivo pelo qual o uso do Git explodiu no início de 2010 pode ser tão simples quanto o fato de que era quando realmente bons recursos para aprender a usá-lo estavam disponíveis.


1
O SVN nunca foi um VCS centralizado líder quando se trata de ramificação e fusão. Hg e Git foram os primeiros VCS de código aberto que lidam bem com ramificação e fusão. Eu não acho que centralizado / distribuído tinha muito a ver com isso.
Ian

1

Escolher um sistema de controle de versão é uma decisão social. A equipe precisa usar a mesma solução. Ao contrário de um editor de texto, que é uma decisão pessoal - desenvolvedores diferentes podem usar editores diferentes e colaborar facilmente.

Portanto, existem efeitos de rede na escolha de um sistema de controle de versão, fazendo com que sistemas que possam ser um pouco melhores ou um pouco mais populares se tornem ainda mais populares.

Por exemplo, eu prefiro darcs para projetos de código aberto, mas descobri que muitos dos meus colaboradores em potencial estavam familiarizados com o git, e recebi mais contribuições mais prontamente para projetos hospedados com git em vez de darcs. Então, acabo usando muito o git em vez de darcs. Então, como eu o uso e publico código no Github, parece que eu o apóio ou até prefiro, o que poderia influenciar outras pessoas a usá-lo.

Os desenvolvedores não querem aprender um novo sistema de controle de origem para cada projeto ao qual contribuem, portanto, beneficia a comunidade em geral ter um padrão "bom o suficiente" e amplamente popular, para que cada equipe e projeto escolha o "melhor "solução no vácuo.

O Github adicionou apenas combustível ao fogo do efeito de rede.


-1

Olhando para o gráfico corrigido na resposta de Michael, mostrando o git-core e o git nos sistemas Debian, a pergunta parece ser por que o git começou a se tornar popular em 2006 nos sistemas Debian e por que cresceu exponencialmente entre 2006-2012.

O motivo pode ser a forte adoção de distribuições Linux baseadas no Debian, como o Ubuntu, que começou a se popularizar entre 2005-2006 e se tornou a distro nº 1 até 2011, quando o Mint, também baseado no Debian, se tornou o nº 1. No final de 2012, o Mint ainda é o número 1 e o Ubuntu, número 3, de acordo com o DistroWatch .

O GitHub, fundado em 2008, forneceu hospedagem git gratuita e, entre 2008 e 2012, tornou-se o principal serviço de repositório de fontes do mundo, com ~ 2,5 milhões de usuários e ~ 4,5 milhões de projetos , de acordo com a Wikipedia no final de 2012.

O Rails e muitos outros projetos passaram do Rubyforge para o GitHub no final dos anos 2000. Além disso, o Bundler foi introduzido na época originalmente em questão (final de 2009), com suporte para instalação / atualização de gemas por meio de uma :gitopção no Gemfile, e o Bundler foi incluído como uma dependência do Rails 3. Projetos em Python, Javascript, C, C ++ , Java, CSS etc. também foram migrados ou iniciados no GitHub.

Aqueles que desejavam contribuir com os projetos no GitHub precisavam dividir o projeto no GitHub, usar um cliente git local para clonar o repositório antes de fazer alterações e enviá-los de volta ao GitHub e fazer uma solicitação pull. Isso foi muito mais simples do que outros métodos usados ​​anteriormente e, sem dúvida, foi um motivo significativo pelo fato de ter sido adotado pelos projetos que se mudaram para o GitHub ou decidiram começar por aí. Isso significava que o git-core / git precisava ser instalado nas distribuições baseadas no Debian para que os desenvolvedores pudessem usar o GitHub.

Portanto, acredito que foi uma combinação de distribuições baseadas no Debian que se tornaram mais populares e adotaram o git cada vez mais devido ao crescimento do GitHub em usuários e projetos, o que provavelmente decorre da hospedagem gratuita e experiência do usuário do GitHub.


-2

Eu acho que muitas pessoas estão confundindo correlação com causalidade.

Os gráficos apresentados mostram correlações entre medidas de popularidade e eventos de gits ... e outras medidas. No entanto, uma correlação não é uma evidência clara de causalidade.

Algumas outras respostas tentam estabelecer relacionamentos com outras coisas; por exemplo, evangelismo de Linus Torsvalds para DVCS, formação do Github, o surgimento de redes sociais. Embora exista evidência de correlação (em uma linha do tempo) não seja tão forte, isso não exclui a causalidade. Especialmente se você aceitar a hipótese do "efeito de rede"; isto é, que existem várias causas.

O ponto principal é que o tipo de evidência disponível não pode mostrar causalidade. Estamos falando de comportamento coletivo de centenas de milhares de pessoas, e as pessoas tomam decisões por diferentes razões ... ou nenhuma razão lógica. Programadores não são diferentes de ninguém.

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.