Por que o Git recebeu tanto hype? ... enquanto outros não? [fechadas]

Nos últimos anos, o hype em torno do Git aumentou bastante. Todo mundo sabe sobre o Git, ninguém sabe sobre alternativas.

Outros como Mercurial parecem passar despercebidos. Ambos foram lançados em 2005 e oferecem funcionalidades semelhantes. Além disso, o Mercurial é geralmente considerado mais fácil de usar, mais intuitivo e possui por muito tempo melhores UIs. Portanto, pode-se supor que essa seria uma alternativa popular, especialmente para os novos no controle de versão distribuído. No entanto, parece desconhecido para a maioria das pessoas, ao contrário do Git, que teve muito sucesso.

O objetivo deste post é tentar entender melhor esse fenômeno.

Como o Git faz parte do bolo? De alguma forma eles usaram um marketing melhor? É porque sua comunidade é mais ... ahem ... "detalhada"? É por causa do nome "Linus"? É por causa de sua imagem nerd?

Qual a sua opinião?

Acredito que serviços como GitHub ou Gitorious são um grande fator. É importante para as pessoas que elas possam hospedar suas coisas em algum lugar e, especialmente, o GitHub é um ótimo serviço para isso.

Para o mercurial, não havia esse serviço quando o DVCS se tornou popular (pelo menos, nenhum que eu conhecia). Você tem Bitbucket agora e provavelmente outros, mas o GitHub já existe há algum tempo, é bem conhecido e fica cada vez melhor.

Vejo muitas respostas para isso que se baseiam nos sentimentos que o autor teve ao ouvir sobre um ou outro SCM. Outros dizem que tudo foi pura sorte. Eu acredito que a sorte pode ser rastreada na história.

Eu vou falar sobre história.

Git e Mercurial foram criados simultaneamente para resolver o mesmo problema. Naquela época, o kernel do Linux era forçado a parar de usar o BitKeeper , um SCM distribuído proprietário que vinha usando há 3 anos. A razão para isso foi que Larry McVoy, CEO da BitMover, a empresa por trás do BitKeeper, parou de distribuir seu software gratuitamente para desenvolvedores de Linux, porque alguém da comunidade Linux fez a engenharia reversa.

Linus Torvalds, insatisfeito com o que já existia, subseqüentemente começou a trabalhar em um novo SCM que ele logo chamaria de Git. Logo depois, Matt Mackall iniciou o projeto Mercurial por razões semelhantes.

Depois de algum tempo desenvolvendo esses projetos separadamente, Matt Mackall apresentou uma versão avançada de seu SCM e a comparou de uma certa maneira, comparando-a com o Git (que tinha apenas algumas semanas). Linus considerou usá-lo em vez do Git para o desenvolvimento do Kernel, mas abandonou a idéia quando percebeu que o Mercurial estava usando o Changesets para registrar modificações de revisão . Ele temia que isso estivesse muito próximo do funcionamento do BitKeeper, e certamente não queria nada que pudesse fazer alguém dizer: "Eles criaram um clone do BitKeeper".

Portanto, o Git foi usado para o desenvolvimento do Kernel em vez do Mercurial, mas ambos eram tecnicamente relevantes. O resultado final é que o Git começou sendo realmente usado onde foi projetado para ser usado, enquanto o Mercurial não foi tão rápido em encontrar seu primeiro grande uso de software livre. Por ter um design muito bom e, graças à perseverança de Matt Mackall, tornou-se famoso e se acostumou a grandes projetos do mundo real.

Hoje, eles são famosos. Qual é o mais famoso é impossível dizer. O Google Code integrou apenas o Git recentemente, enquanto ele possuía o Mercurial por um longo tempo. Muitos projetos realmente grandes e famosos também usam.

Acho que o que quero dizer é que, quando a própria razão pela qual você iniciou um projeto desaparece, é mais difícil obter popularidade, mas ainda possível.

Bazaar é outro SCM que é muito famoso no mundo GNU, mas não muito fora disso, porque foi construído com a intenção de satisfazer a comunidade GNU. O software costuma ir aonde seus criadores desejam ir, e não mais.

Por outro lado, os SCMs distribuídos são vencedores claros. Não vejo muitos SCMs não distribuídos amplamente utilizados por aí.

Linus Torvalds

Linus é um grande defensor do Git e o promoveu fortemente ao grupo principal do linux por anos e cresceu a partir daí. Ouso dizer que é inteiramente devido à influência de Linus sobre a comunidade * nix.

Pessoalmente, ainda uso o Subversion, mas isso é preferível e não utilitário.

O ponto de dor usual com o sistema de controle de versão é a fusão de ramificações .

Você precisa ter tentado quando não funciona para entender o quão doloroso pode ser e como é importante trabalhar, para trabalhar livremente com galhos.

Aprendendo que Linus Torvalds escreveu o git para fazer isso da maneira certa, e que, em uma situação, ele usou o git para mesclar doze ramos ao mesmo tempo, esse é um argumento muito convincente para o git ser interessante.

Eu estava na situação há cerca de um ano em que tive que escolher entre hg e git, e a fusão acima foi um fator importante na escolha do git. A segunda foi que a organização Eclipse mudou para o git, portanto, esperava-se que as ferramentas do Eclipse fossem boas para projetos Java. Com o lançamento do Eclipse 3.7, isso aconteceu. Talvez estivéssemos entre 6 e 9 meses mais cedo.

Para necessidades diferentes, o hg pode ser igualmente útil. A Sun escolheu para o seu VCS com base em uma investigação muito cuidadosa. Você pode encontrar os white papers e ver quais eram seus raciocínios.

EDIT: Observe, não estou dizendo que há algo que a Mercurial não pode fazer, apenas para Java com Eclipse - que é o nosso foco principal - as forças de mercado atualmente são mais fortes para o git, mesmo no Windows, e precisamos nos apoiar dos outros, não seus pés.

Em vez de dizer por que git ou mercurial é melhor e dizer que é a única razão de sua popularidade, vou me concentrar na comunidade.

Como destaquei anteriormente , a comunidade Git é muito alta e arrogante. A maioria defenderá vigorosamente seu precioso programa. A maioria das guerras Git vs Mercurial que eu vi foram iniciadas por pessoas git que se perguntavam por que todo mundo na Terra não está usando o santo git. Sites como o whygitisbetterthanx.com até mostram essa arrogância na introdução, escrita para atrair outras pessoas.

Não estou dizendo que todo mundo é assim, mas na maioria das vezes, quando eu encontrei pessoas git, sites e sites pró-git, senti que o git estava sendo enfiado na minha garganta em vez de oferecido como um DVCS viável sistema.

Por outro lado, outras comunidades DVCS não são tão barulhentas. Eu não sabia que o Mercurial existia até ver um "Qual é o melhor DVCS?" pergunta sobre SO. Enquanto o git aparece em todos os lugares, outros DVCS levam tempo para serem encontrados.

Não acho que o Mercurial seja particularmente discreto. O Kiln é baseado em Hg e há um bom suporte em IDEs como Eclipse e Netbeans há um tempo.

A maioria dos desenvolvedores com quem converso parece preferir Hg por causa do melhor suporte ao Windows. Se fôssemos desenvolvedores do Linux, poderia ser uma história diferente.

Você também está perdendo o "Bazaar", que é o verdadeiro "DVCS esquecido".

Certamente eu concordo que Linus é um cara muito carismático e um nerd alfa quase sem igual, então muitas pessoas gravitam no Git por causa disso. Além disso, o "mito da criação" do Git é muito convincente com Linus trabalhando por 6 dias para criar o Git e descansando no sétimo - ou algo assim. Quando um produto tem uma história memorável, é mais fácil ganhar força.

É uma opinião humilde, mas o git pode ter todo esse hype por causa de dois parâmetros:

1. É muito eficiente
2. É divertido de usar (de alguma maneira muito específica para cientistas da computação)

Além disso, o git tem um aplicativo matador como o github, e alguns projetos muito populares decidiram usá-lo, o que lhe deu muita visibilidade.

Existem três fatores em ação aqui, "mídia geek beta", "a hora certa" e "siga o líder"

Beta Geek Media

Existem vários canais que discutem "atividades nerds". Eles certamente cobririam a aparência de um novo sistema de controle de versão, mas cobrem mais o git. Por quê? Porque Linus Torvalds o escreveu inicialmente, discutiu publicamente e usou-o como uma solução para seu bem-divulgado problema com o bitkeeper. Efetivamente, sempre que houver uma guerra de fogo contra o lkml, a mídia beta geek escreverá um artigo sobre isso. A discussão sobre o Git começou no lkml, para obter mais cobertura do que outras alternativas. E os nerds beta que lêem slashdot como se fosse Variety comiam. O resultado final disso é que o git tem dez vezes mais artigos do que mercurial.

Chegou a hora

Grandes projetos de código aberto com muitos colaboradores têm problemas com o controle centralizado de código-fonte. À medida que o código aberto cresce, e os projetos se tornam mais propensos a ter muitos colaboradores, o problema fica pior. O Linux é provavelmente o projeto mais conhecido que sofre com isso, mas existem muitos outros. Com muitos projetos chegando a esse ponto, era necessário algum tipo de VCS avançado. Git, Mercurial e Bazaar foram os grandes vencedores aqui. Arch e Monotone chegaram um pouco cedo demais e perderam a onda do hype.

Siga o Mestre

Grandes projetos têm seguidores que fazem check-out e constroem o código regularmente, mesmo que não contribuam. Os seguidores se familiarizam com as ferramentas necessárias para buscar o projeto que seguem, para que essas ferramentas sejam mais usadas. Vamos dar uma olhada nos projetos de "grande atração" para os três grandes DVCSs:

• Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
• Mercurial : Java, Mozilla, Python
• Bazar : Ubuntu, Emacs

O Git tem mais projetos de "grande atração" usando-o, portanto, mais pessoas estão familiarizadas com o git, há mais tutoriais do git escritos.

É principalmente apenas um exagero de auto-reforço. O Git é o mais popular, por isso recebe mais publicidade, o que leva a que ele se torne mais popular.

Git, Hg e Bzr são todos sistemas DVCS perfeitamente bons, mas um número assustador de pessoas equipara DVCS a Git e acha que todos os recursos encantadores de um DVCS são exclusivos do Git. E assim eles usam o Git, recomendam o Git e dizem coisas como "O Git é melhor porque pode fazer fusões de polvo" (o mesmo pode Bazaar) ou "Git é melhor porque é distribuído" (assim como qualquer DVCS, daí o nome ) ou "Git é melhor porque facilita a ramificação e a fusão" (novamente, isso é verdade para todos os DVCS).

Infelizmente, porque sinto que as alternativas também têm muito a oferecer, e prefiro que as pessoas escolham o Git por seus pontos fortes, do que simplesmente porque pensam que DVCS == Git.

Quando alguém descobre como os DVCS são inteligentes, ao serem apontados para um DVCS específico, eles geralmente não dizem aos outros "ei, os DVCS são ótimos, você deve usá-los", mas "o DVCS que eu aprendeu sobre DVCS é ótimo, você deve usá-lo ".

Github. O Github é pioneiro na codificação social. Ele transformou o controle de versão em uma plataforma social que chamou muita atenção e obviamente suporta apenas o Git. Mídia social = maior adoção. O Bitbucket está ganhando força graças a muitos novos recursos, tornando-o um provável rival :)

Bem, na verdade, acho que o hype é sobre todos os DSVCs.

Mas os defensores do git são apenas mais vocais, geralmente mais agressivos em seus comentários para serem honestos e gostam de falar sobre isso em todos os lugares.

Suspeito que o Mercurial seja amplamente usado, certamente tão frequentemente quanto o git, talvez mais (Microsoft e outras grandes empresas o usam agora), mas as pessoas que usam o Mercurial na maioria das vezes só queriam um DSVC que pudessem entender rapidamente, não algo para basear uma religião. Portanto, eles são menos vocais e mais reativos nas discussões do que proativos, como alguns usuários do git.

Bazaar não é muito comentado, certamente, porque apenas alguns grandes projetos conhecidos o utilizam e nenhuma outra grande empresa além da Canonical é conhecida por usá-lo. Compare com o Google (git, mercurial, svn) e grandes projetos de código aberto, por exemplo, e você pode ver por que não é realmente mencionado. O Fossil é outro interessante para um nicho de desenvolvedores, então acho que é normal e bom que sejam ouvidos apenas por aqueles que pesquisam os recursos que fornecem (como wiki incorporado, rastreamento de problemas e fórum).

Dito isto, acho que estamos começando lentamente o ciclo do hype e muitos desenvolvedores que usaram várias soluções diferentes podem começar a ver qual deles atende às suas necessidades.

Além disso, o Google Code Hosting e o SourceForge agora permitem tanto o git quanto o mercurial, tornando-se mais uma opção específica do projeto do que antes quando você escolheu o git por causa dos recursos do GitHub.

Não há guerra real, apenas uma variedade interessante de ferramentas.

Sei que já existem muitas respostas para essa pergunta, mas achei que poderia acrescentar um pouco mais de perspectiva.

Eu usei o Bazaar praticamente desde que foi criado para várias coisas. A maior coisa que eu usei foi no projeto AllTray, para o qual sou (atualmente) o único desenvolvedor e mantenedor. Bazar é bom. Ele simplesmente funciona, fica fora do meu caminho e quase nunca tenho que olhar para uma página --help ou a página de manual. Dito isto, há algumas desvantagens:

1. Muita funcionalidade que possui, que sem dúvida deveria fazer parte do núcleo do VCS, não é. Coisas como a capacidade de executar uma bissecção da história, executar uma saída longa através de um pager ou ter ramificações "colocadas" (por exemplo, repositórios no estilo git) são fornecidas como plug-ins.
2. Muitos plugins não são tão estáveis. Por exemplo, a funcionalidade de ramificações colocadas não parece funcionar bem no servidor (pelo menos, eu nunca consegui fazê-la funcionar, ela tende a erro ao dizer que a ramificação no caminho especificado não existe quando é bem ali na sua frente e você pode ver a coisa sangrenta).
3. Não possui operação de "clone", você puxa galhos um de cada vez. Você precisa fazer um trabalho extra se quiser ter um repositório para poder puxar novas ramificações com eficiência.
4. Para alguns projetos, é dolorosamente lento. Tente "bzr branch lp: mysql" algum dia.
5. Falta um forte suporte para ganchos; você pode escrever plugins bzr que fornecem ganchos, mas não há uma maneira padrão de ter scripts de ganchos arbitrários no servidor.

Recentemente, mudei para o git para o desenvolvimento do AllTray e estou pensando em migrar rapidamente todos os meus projetos para o git. Há um pouco de tempo adiantado gasto para conhecer as cordas, mas parece valer a pena. Algumas coisas que eu notei:

1. git clone é uma operação relativamente rápida e fornece informações sobre todas as ramificações existentes no repositório que você clonou.
2. A adição de repositórios remotos adicionais é simples e, portanto, você pode acompanhar muitos repositórios diferentes que possuem várias ramificações.
3. O livro Pro Git está disponível on-line e em vários formatos, inclusive para dispositivos de leitor de e-book - e não é uma leitura difícil.
4. O git parece muito mais fácil de estender que o Bazaar, e você não precisa usar nenhuma API específica para fazer isso. (NB: isso é uma vantagem e uma desvantagem.)
5. O git possui bissecção embutida e não posso enfatizar a utilidade desse recurso o suficiente.
6. O GitHub é bastante agradável.
7. O gitosissistema também é bastante agradável. Eu nem tenho certeza de como alguém implementaria isso além de um plug-in no Bazaar, e não consigo imaginar que seja algo tão eficiente quanto isso.

Para encurtar a história: Eu uso o bzr há muito tempo, mas o git está rapidamente provando sua grandiosidade para mim.

Usando o git, você tende a permanecer sempre no mesmo diretório local ao desenvolver e simplesmente git checkout branchnamealterna entre os ramos (eu uso ramos de recursos "leves" o tempo todo, portanto, esse é um recurso muito importante para mim).

Observando a documentação e os tutoriais da Mercurial, parece que a maneira preferida de lidar com diferentes ramos do desenvolvimento é criar novos repositórios por clonagem. Este tutorial é um exemplo.

Eu acredito que você pode fazer a mesma coisa no Mercurial e no git, mas por algum motivo a documentação do Mercurial (que eu li) quase sempre mostra ramificações criando um clone de repositório.

(Eu uso o git diariamente. Tenho pouca experiência com mercurial, brinquei com ele e segui alguns tutoriais)

Não sei quantos discursos desse tipo já vi nas últimas semanas, mas todos parecem considerar o fato de que Mercurial e / ou Bazaar são objetivamente melhores que o Git. A usabilidade parece ser um tema comum. Sim, aprender Git foi surpreendentemente difícil depois de usar o CVS e o Subversion, mas neste momento eu não gostaria de trocá-lo por nenhum outro VCS, a menos que constituísse outra mudança de paradigma . E apontar para uma tabela de recursos vai me dizer muito pouco sobre como é flexível, extensível, seguro ou sem esforço . Por exemplo, por padrão, git-diff usa cores e um pager. Claro que posso conseguir o mesmo com diff ... | colordiff | less -Ralgo assim, mas deve ser óbvio por que um é superior ao outro.

Para ser justo, acho que os advogados git vs. mercurial são poucos e distantes entre os advogados git vs. centralizados. No entanto, é fácil resumir os motivos:

Git é controle de versão para programadores. Mercurial é o controle de versão para empresas. Centralizado foi uma primeira tentativa adequada de inventar o controle de versão, especialmente considerando que ele foi projetado antes da revolução do computador pessoal.

O que quero dizer com controle de versão para programadores é que os programadores em geral favorecem a flexibilidade, e não a facilidade de aprendizado. Afinal, estamos dispostos a passar anos aprendendo idiomas esotéricos para ter a flexibilidade de fazer com que os computadores façam o que os não treinados não podem. O Git oferece aos programadores a flexibilidade de usá-lo como bem entenderem, às custas de levar mais tempo para aprender como usar essa flexibilidade com segurança. Ele permite que restrições sejam impostas para impor políticas, mas não é assim que sai da caixa. Observe que eu disse facilidade de aprendizado em vez de facilidade de uso . Depois de aprender, o git é tão fácil de usar quanto qualquer outro VCS, e geralmente mais fácil devido à maior velocidade e recursos.

Alguns programadores aprendem o suficiente para fazer o que querem e depois resistem a aprender novas maneiras de fazê-lo. As empresas contratam e empregam muitas dessas pessoas, portanto, desejam que as alterações nas ferramentas utilizadas tenham um certo grau de familiaridade. As empresas também querem que seus programadores tenham flexibilidade suficiente para realizar seus trabalhos, mas não tanto quanto dificultar o treinamento ou a migração inicial. É aqui que o mercurial se encaixa. Ele tem a maior parte do poder do git, mas um caminho de migração um pouco mais fácil.

Não acho justo dizer que o git só é popular por causa do hype ou do apoio de Linus. Provavelmente, isso é responsável por muitas pessoas tentando , mas elas se apegam e a promovem porque funciona bem para elas, pura e simples.

O desenvolvimento do NetBSD usa CVS e isso é tudo que é importante.

Tem um nome mais rápido e conciso que se presta bem a trocadilhos.

Recentemente, eu estava procurando por um sistema de controle de versão para projetos pessoais, então apenas tentei vários deles. Sou praticamente analfabeto na linha de comando e ouvi dizer que, embora as GUIs estivessem disponíveis, o Git era realmente destinado a ser usado através da linha de comando, o que me deixou um pouco hesitante. Honestamente, foi ridiculamente fácil de pegar, e eu estou gostando muito. A documentação é um fator enorme na adoção de uma nova tecnologia, e o Git possui toneladas de documentação ridiculamente simples, clara e disponível. As outras alternativas, como SVN e Bazaar, foram ótimas, mas simplesmente não tornaram tão fácil quanto o Git. O Github também é um fator importante, pois se tornou tão central no movimento de código aberto no momento. Ter uma localização centralizada (ironicamente) para trocar códigos e projetos é uma mudança de jogo.

Apenas meus 2 ¢ - eu escolhi o git em vez das alternativas, porque está escrito em C, em vez de um idioma de rádio ou de alto nível acadêmico. Os benefícios são que é rápido e eficiente e que eu posso realmente RTFS se encontrar bugs ou comportamentos que não posso explicar. Também possibilita o uso em pequenos ambientes de desenvolvimento auto-hospedados que não incluem intérpretes / tempos de execução gigantescos, o que significa que posso extrair diretamente de um repositório git e compilar nesses sistemas, em vez de ter que buscar a fonte mais recente em outro lugar e o rsync.

Você pode estar interessado em ler por que o projeto de área de trabalho do GNOME escolheu git em vez de hg e bzr, quando decidiu mudar do svn alguns anos atrás. Houve muitas discussões religiosas acaloradas ao longo do curso, mas esta página do GNOME Wiki resume bem os prós e contras à medida que se aplicavam a essa comunidade em particular.

Sem mencionar que a Apple agora se envolveu em enviá-lo para a comunidade de objetivos c, se você criou um novo aplicativo no Xcode 4 recentemente, deve ter notado que ele pergunta automaticamente se você deseja fazer um repo Git.

O Xcode 4 concedido existe há apenas alguns meses e não influencia o sucesso anterior do Gits, mas todos sabemos o quão popular a Apple pode fazer as coisas em um curto espaço de tempo.

Atualmente, estou mudando de hg (forno) para git (github). Eu usei o forno por cerca de um ano agora. Para mim, hg não tem desvantagem. Eu posso fazer tudo o que for preciso. Então é ótimo.

Por que estou usando agora?

Existem apenas três razões agora.

1. O gitHub oferece dicas que são ótimas
2. O gitHub oferece ótimos recursos sociais
3. Enquanto fazia apresentações e workshops para desenvolvedores, eu sempre publicava minhas amostras no hg e no git. No git, tenho cerca de 10 vezes mais visitantes do que no hg !!

Eu acho que o terceiro é o mais importante.

Thorsten

Pura sorte, acho, até agora quase impossível provar por que algo funcionou e outro não. Linus pode construir algo espetacular e não ter sucesso.