Por que o súbito aumento no número de apresentadores do Git no Debian popcon graph em 2010-01?

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

Portanto, um gráfico melhor é:

O que mostra que a popularidade não aumentou drasticamente (pegue a linha verde para a parte esquerda até que eles se cruzem, então pegue a linha vermelha).

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

Este é um gráfico que mostra as instalações numéricas de git e git-core ao longo do tempo:

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

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

Depois veio o git. O que forçou o radar de todo mundo foi que havia um enorme projeto público que imediatamente o adotou. O Git tem muitos usuários de graça - se você fosse fazer uma séria invasão do kernel, você usaria o git. Embora eu não possa ter 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. Ele também, por suas verrugas iniciais, era mais estável do que a maioria dos DVCS concorrentes na época. Os Darcs, por exemplo, poderiam ser colocados em um estado inconsistente que requeria um utilitário absurdamente complexo (quadrático? Fatorial? Não me lembro com certeza, mas era ruim ) para corrigir. O Git sempre foi mais estável.

A partir de sua grande base de usuários, ele apenas "sangrou".

Todo projeto, comercial ou de código aberto, precisa dessa massa crítica. Darcs não entendeu. Nem Mercurial. Pense de novo. Muitos projetos menores usam isso. Há provavelmente até mesmo um número de usuários comerciais. Mas qual é a sua grande história de sucesso?

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

Então, para resumir, foi um bom produto que apareceu na hora certa e conseguiu uma base de usuários grande e dedicada.

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

O motivo pelo qual acredito que o Git se tornou tão popular é que, por causa de sites como o GitHub, você teve um efeito de rede nas ferramentas de controle de versão. Isso não era visto anteriormente, já que você compartilharia código em um projeto ou empresa.

Eu me lembro especificamente de mudar para o Git e o Github porque todos os projetos nos quais eu estava interessado em seguir e contribuir tinham feito o mesmo, assim como os desenvolvedores que eu associo.

Esse é um efeito de rede.

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

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

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

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

Atualização:Euseiqueafonteacimapodenãotersidoprecisa,masexistemmuitasfontesdedadosquedemonstramqueoGittemcrescidoexponencialmentenosúltimosanos.

Gráfico1:MençõesdoGitemanúnciosdeemprego

E a pesquisa Eclipse, que mostra que a participação de mercado do Git foi de 13% em 2011 para 27% em 2012 . Crescimento incrível.

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

Só para deixar claro, este gráfico mostra a instalação do git em sistemas Debian.

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

Estou surpreso que ninguém mencionou o Github como um dos maiores motivos para o Git ganhar popularidade . Eles empurraram o git mainstream.

O Github foi lançado em abril de 2008 e, dentro de 1-2 anos, ganhou popularidade. E então, quando você vê uma súbita explosão de uso do git / git-core é principalmente devido aos usuários do github de 2Million e seus repositórios de 3.7million. O Github tornou o git fácil de usar. Bitbucket estava lá, mas o github fez isso sem esforço. Tenho certeza que se os caras do github escolhessem Hg no lugar de git, deveríamos ter visto o mesmo aumento no uso de Hg.

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

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

Por que a súbita explosão no início de 2010, meu palpite é bastante prosaico. O Git é brilhante, mas não é intuitivo para um iniciante.

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

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

A escolha de 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 diferentes editores e colaborar facilmente.

Então, há efeitos de rede na escolha de um sistema de controle de versão, fazendo com que sistemas que podem 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 mais de meus potenciais colaboradores estavam familiarizados com o git, e recebi mais contribuições mais prontamente para projetos hospedados com git em vez de darcs. Então, acabei usando muito o git em vez de darcs. Então, porque eu uso e publico código no Github, parece que eu o endosso ou posso até preferir, o que poderia influenciar outros a usá-lo.

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

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

Analisando o gráfico corrigido na resposta de Michael, mostrando o git-core e o git nos sistemas Debian, o pergunta parece ser o motivo pelo qual o git começou a se tornar popular em 2006 nos sistemas Debian e porque cresceu exponencialmente entre 2006-2012.

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

Rails e muitos outros projetos mudaram 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 instalar / atualizar gems através de uma opção :git no Gemfile, e Bundler foi incluído como uma dependência do Rails 3. Projetos em Python, Javascript, C, C ++, Java, CSS, etc. também migraram para ou iniciado no GitHub.

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

Então, eu acredito que foi uma combinação de distribuições baseadas no Debian se tornando mais populares e aumentando a adoção do gitHub devido ao crescimento de usuários e projetos do GitHub, o que provavelmente deriva da hospedagem e experiência do usuário do GitHub.

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

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

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

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