Nos últimos anos, o hype em torno do Git aumentou muito. Todo mundo sabe sobre o Git, ninguém sabe sobre alternativas.
Outros como o Mercurial parecem passar despercebidos. Ambos foram lançados em 2005 e fornecem funcionalidades semelhantes. Além disso, o Mercurial é geralmente considerado mais fácil de usar, mais intuitivo e teve, por um longo tempo, melhores IUs. Portanto, pode-se supor que essa seria uma alternativa popular, especialmente para aqueles que são 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 consegue fazer parte do bolo? Será que eles de alguma forma usam marketing melhor? É porque a sua comunidade é mais ... ahem ... "verbose"? É por causa do nome "Linus"? É por causa de sua imagem nerd?
Qual sua opinião?
Acredito que serviços como o link ou link é um grande fator. É importante para as pessoas que elas podem hospedar suas coisas em algum lugar e, especialmente, o github é um ótimo serviço para isso.
Para o mercurial, não havia tal serviço quando os dvcs se tornaram populares (pelo menos nenhum deles estava ciente). Você tem link agora e provavelmente outros, mas o github está lá há algum tempo, é bem conhecido e fica cada vez melhor.
Eu vejo muitas respostas para isso que dependem dos sentimentos que o autor tinha quando ouvia 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 sair de um período durante o qual estava usando o BitKeeper , um SCM distribuído proprietário que os serviu bem por muitos anos.
Na verdade, Larry McVoy, CEO da BitMover, a empresa por trás do BitKeeper, parou de oferecer seu software gratuitamente para desenvolvedores Linux, porque alguém dentro da comunidade Linux havia feito engenharia reversa.
Linus Torvalds, insatisfeito com o que já existia, subseqüentemente começou a trabalhar em um novo SCM que ele logo chamaria Git. Rapidamente, Matt Mackall iniciou o projeto Mercurial por razões semelhantes.
Após algum tempo desenvolvendo esses projetos separadamente, Matt Mackall apresentou uma versão avançada de seu SCM e comparou-o de uma certa maneira, comparando-o ao Git (que tinha apenas algumas semanas). Linus considerou usá-lo em vez de Git para o desenvolvimento do Kernel, mas desistiu da ideia quando percebeu que O Mercurial estava usando o Changesets para registrar modificações na revisão . Ele temia que isso fosse muito próximo do modo como o BitKeeper funcionava, e ele certamente não queria nada que pudesse fazer alguém dizer: "Eles criaram um clone do BitKeeper".
O Git foi, portanto, usado para o desenvolvimento do Kernel em vez do Mercurial, mas ambos eram tecnicamente relevantes. O resultado final é que o Git começou sendo usado onde foi projetado para ser usado, enquanto o Mercurial não foi tão rápido para encontrar seu primeiro grande uso de software livre. Porque foi dotado de um design muito bom e, graças à perseverança de Matt Mackall, acabou se tornando famoso e se acostumou a grandes projetos do mundo real.
Hoje, ambos são famosos. Qual deles é mais famoso é impossível dizer. O Google Code só integrou o Git recentemente, enquanto o Mercurial já durava muito tempo. Muitos projetos realmente grandes e famosos usam ambos.
Eu acho que o que eu quero dizer é, quando a razão pela qual você iniciou um projeto desaparece, é mais difícil ganhar popularidade, mas ainda é viável.
Bazaar é outro SCM que é muito famoso no mundo GNU, mas não tanto fora dele, porque foi construído com a intenção de satisfazer a comunidade GNU. O software geralmente vai para onde seus criadores querem 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 strongmente para o núcleo do grupo linux por anos e cresceu a partir daí. Eu diria que é inteiramente devido à influência de Linus sobre a comunidade * nix.
Pessoalmente, eu ainda uso o Subversion, mas isso é da preferência, e não da utilidade.
O ponto problemático comum com o sistema de controle de versão é ramificação .
Você precisa ter tentado quando não funciona para entender o quão doloroso pode ser e como é importante ter trabalho, para trabalhar livremente com as agências.
Aprendendo que Linus Torvalds escreveu git para fazer isso direito, e que alegadamente em uma situação ele usou git para mesclar doze filiais juntas de uma vez, este é um argumento muito convincente para o git ser interessante .
Eu estava na situação há um ano atrás, onde eu tive que escolher entre o hg e o git, e a fusão acima foi um fator importante na escolha do git. A segunda foi que a organização do Eclipse mudou para o git, portanto, esperava-se que o conjunto de ferramentas do Eclipse fosse bom para projetos Java. Com o lançamento do Eclipse 3.7, isso aconteceu. Nós estávamos talvez 6 a 9 meses mais cedo sobre isso.
Para necessidades diferentes, o hg pode ser igualmente útil. A Sun escolheu-o para o seu VCS com base numa muito investigação cuidadosa. Você pode encontrar os white papers e ver quais foram seus raciocínios.
EDIT: Note, não estou dizendo que há algo que o Mercurial não pode fazer, apenas para Java com Eclipse - que é nosso foco principal - as forças de mercado são mais strongs para o git, mesmo sob o Windows, e precisamos nos posicionar nos ombros dos outros, não nos pés deles.
Em vez de dizer por que o git ou o mercurial é melhor e dizer que é a única razão pela qual é popular, vou me concentrar na comunidade.
Como eu destaque anterior , a comunidade Git é muito barulhenta e arrogante. A maioria defenderá vigorosamente seu precioso programa. A maioria das guerras Git vs Mercurial que eu vi foram iniciadas por pessoas que estavam imaginando por que todos na Terra não estão usando o sagrado imbecil. Sites como whygitisbetterthanx.com até mostram essa arrogância na introdução, que foi escrita para isca chama outros.
Eu não estou dizendo que todo mundo é assim, mas na maioria das vezes quando eu encontrei git pessoas, sites pro-git e blogs pro-git eu senti como git estava sendo empurrado pela minha garganta em vez de oferecido como um sistema DVCS viável.
Por outro lado, outras comunidades de DVCS não são tão barulhentas. Eu não sabia que o Mercurial existia até que eu vi um "Qual é o melhor DVCS?" pergunta sobre SO. Enquanto o git aparece em todo lugar, outros DVCs demoram para encontrar.
Eu não acho que o Mercurial seja particularmente discreto. Forno é construído em Hg & houve um bom suporte em IDEs como o Eclipse & Netbeans por um tempo agora.
A maioria dos desenvolvedores com quem falo parece preferir o Hg por causa do melhor suporte do Windows. Se fôssemos desenvolvedores de Linux, poderia ser uma história diferente.
Você também está sentindo falta do "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 gravitariam para o 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 parecido. Quando um produto tem uma história memorável, é mais fácil ganhar força.
É uma opinião humilde, mas git pode ter todo esse hype por causa de dois parâmetros:
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 beta geek", "a hora é certa" e "siga o líder"
Existem vários canais que discutem "atividades nerds". Eles certamente cobririam a aparência de um novo sistema de controle de versão, mas eles cobrem mais. Por quê? Porque Linus Torvalds escreveu isso inicialmente, discutiu publicamente sobre isso e usou-o como uma solução para seu problema bem divulgado com o bitkeeper. Efetivamente, sempre que houver uma guerra em lkml, a mídia beta geek escreverá um artigo sobre isso. A discussão do Git começou no lkml, então ele teve mais cobertura do que outras alternativas. E os geeks beta que lêem slashdot como se fosse Variety , comeram. O resultado final disso é que o git tem dez vezes mais artigos do que mercurial.
Grandes projetos de código aberto com muitos contribuidores têm problemas com o controle de origem centralizado. À medida que o código aberto cresce e os projetos se tornam mais propensos a ter muitos colaboradores, o problema piora. O Linux é provavelmente o projeto mais conhecido que sofre com isso, mas há muitos outros. Com muitos projetos atingindo esse ponto, algum tipo de VCS avançado era necessário. Git, Mercurial e Bazaar foram os grandes vencedores aqui. Arch e Monotone estavam um pouco adiantados demais e perderam a onda do hype.
Grandes projetos têm seguidores que fazem check-out e criam 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 "big draw" para os três grandes DVCSs:
O Git tem mais projetos "big draw" usando-o, assim mais pessoas estão familiarizadas com o git, existem mais tutoriais git escritos.
É principalmente apenas hype auto-reforço. O Git é o mais popular, por isso é mais divulgado, o que faz com que ele se torne mais popular.
O Git, o Hg e o Bzr são sistemas DVCS perfeitamente bons, mas um número assustador de pessoas compara o DVCS ao Git e acha que todos os recursos adoráveis de um DVCS são exclusivos do Git. E então eles usam o Git, e recomendam o Git, e dizem coisas como "o Git é melhor porque ele pode fazer fusões de octopus" (So Bazaar), ou "o Git é melhor porque é distribuído" (é qualquer DVCS, daí o nome), ou "O Git é melhor porque facilita a ramificação e fusão" (mais uma vez, isso é verdade para todos os DVCS).
Infelizmente, porque eu sinto que as alternativas têm muito a oferecer também, e eu preferiria que as pessoas escolhessem o Git por suas forças únicas, do que simplesmente porque elas acham que o DVCS == Git.
Quando alguém descobre como os DVCS são inteligentes, sendo apontados para um DVCS específico, eles geralmente não vão dizer aos outros "hey, os DVCS são ótimos, você deve usá-los", mas sim, "o DVCS que I aprendeu sobre DVCS'es é ó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 atraiu muita atenção e, obviamente, apenas suporta o Git. Mídia social = maior adoção. O Bitbucket está ganhando fôlego apesar de ter muitos novos recursos, tornando-se um provável rival:)
Bem, na verdade, acho que o hype é sobre todos os DSVCs juntos.
Mas os defensores do git são apenas mais vocais, muitas vezes mais agressivos em seus comentários para serem honestos e gostam de falar sobre isso em todos os lugares.
Eu suspeito que o Mercurial seja amplamente utilizado, certamente tão frequentemente quanto o git, talvez mais (a Microsoft e outras grandes empresas o usam agora), mas as pessoas que usam o Mercurial na maioria das vezes só querem um DSVC. religião em. Então eles são menos vocais e mais reativos nas discussões do que proativos como alguns usuários git.
Bazaar não é muito falado, certamente, porque apenas poucos grandes projetos conhecidos o usam e nenhuma outra grande empresa do que a 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 falado. Fossil é outro que é interessante para um nicho de devs, então eu acho que é normal e bom para eles serem ouvidos apenas por aqueles que buscam os recursos que eles fornecem (como wiki embutido, rastreamento de problemas e fórum).
Dito isso, acho que estamos desacelerando lentamente o ciclo de hype e muitos desenvolvedores usaram vários diferentes soluções podem começar a ver qual delas atende às suas necessidades.
Além disso, o Google Code Hosting e o SourceForge agora permitem tanto o git quanto o mercurial, então está se tornando 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 interessante variedade de ferramentas.
Eu sei que existem muitas respostas para esta questão, mas eu senti que poderia adicionar um pouco mais de perspectiva.
Eu usei o Bazaar praticamente desde que foi criado para várias coisas. A maior coisa que usei foi o projeto AllTray, do qual eu 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 de ajuda ou para a página de manual dele. Dito isto, existem algumas desvantagens:
Eu mudei recentemente para o git para o desenvolvimento do AllTray, e estou pensando muito em migrar todos meus projetos para o git. Há um pouco mais de tempo gasto na hora de conhecer as cordas, mas parece valer a pena. Algumas coisas que eu notei:
git clone é uma operação relativamente rápida e fornece informações sobre todas as ramificações existentes no repositório que você clonou. gitosis também é muito bom. Eu nem tenho certeza de como alguém implementaria isso senão como um plugin no Bazaar, e eu não posso imaginar que seria tão eficiente quanto isso. Resumindo: eu usei o bzr por muito tempo, mas git está rapidamente provando sua grandiosidade para mim.
Usando o git, você tende a permanecer sempre no mesmo diretório local quando faz o desenvolvimento, e simplesmente git checkout branchname para alternar entre ramificações (eu uso ramificações de recursos "leves" o tempo todo, então esse é um recurso muito importante para mim).
Olhando para a documentação e tutoriais do Mercurial, parece que a maneira preferida de lidar com diferentes ramos de desenvolvimento é criar novos repositórios por clonagem. Este tutorial é um exemplo.
Eu acredito que você pode fazer a mesma coisa no Mercurial como no git, mas por alguma razão a documentação do Mercurial (que eu li) quase sempre mostra ramificação criando um clone do repositório.
(Eu uso o git diariamente. Eu tenho pouca experiência com o mercurial, eu toquei com ele e segui alguns tutoriais)
Eu não sei quantos comentários curtos eu vi nas últimas semanas, mas todos parecem considerar o fato de que Mercurial e / ou Bazaar são objetivamente melhores que Git. Usabilidade parece ser um tema comum. Sim, aprender Git foi surpreendentemente difícil depois de usar CVS e Subversion, mas neste momento eu não gostaria de trocá-lo por qualquer 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 -R ou algo assim, mas deveria ser óbvio porque um é superior ao outro.
Git is version control for programmers. Mercurial is version control for enterprises. Centralized was an adequate first try at inventing version control, especially considering it was designed before the personal computer revolution.
O que quero dizer com controle de versão para programadores é que os programadores em geral favorecem a flexibilidade sobre a facilidade de aprendizado. Afinal, estamos dispostos a passar anos aprendendo idiomas esotéricos para ter a flexibilidade de fazer os computadores fazerem o que os não treinados não conseguem. O Git dá aos programadores a flexibilidade de usá-los como bem entenderem, em detrimento de demorar mais para aprender como usar essa flexibilidade com segurança. Ele permite que restrições sejam postas em prática para reforçar as políticas, mas não sai dessa maneira. Note que eu disse facilidade de aprender ao invés da facilidade de uso . Uma vez que você aprende, o git é tão fácil de usar como qualquer outro VCS, e geralmente mais fácil devido ao aumento de velocidade e recursos.
Alguns programadores aprendem o suficiente para fazer o que querem, depois resistem a aprender novas maneiras de fazê-lo. As empresas contratam e empregam muitas dessas pessoas, por isso querem que qualquer mudança nas ferramentas usadas por elas tenha um certo grau de familiaridade. As empresas também querem que seus programadores tenham flexibilidade suficiente para realizar seus trabalhos, mas não tanto para dificultar o treinamento ou a migração inicial. É aí 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.
Eu não acho que seja justo dizer que git é popular apenas por causa do hype, ou o endosso de Linus. Isso provavelmente é responsável por muitas pessoas que tentam usá-lo, mas eles o mantêm e o promovem porque funciona bem para eles, pura e simplesmente.
Ele tem um nome mais rápido e mais conciso que se presta bem a trocadilhos.
Recentemente, eu estava procurando por um sistema de controle de versão para projetos pessoais, então eu tentei um monte 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 por meio da linha de comando, o que me deixou um pouco hesitante. Honestamente, foi ridiculamente fácil de aprender, e estou realmente gostando. A documentação é um grande fator na adoção de uma nova tecnologia, e o Git tem toneladas de documentação ridiculamente simples, clara e disponível. As outras alternativas, como SVN e Bazaar, eram ótimas, elas simplesmente não faziam isso tão fácil quanto o Git. O Github também é um grande fator, já que se tornou tão central para o movimento open source no momento. Ter uma localização (ironicamente) centralizada para trocar códigos e projetos é uma mudança em si mesma.
Just my 2 ¢ - Escolhi as alternativas porque está escrito em C em vez de uma linguagem radtool ou uma linguagem de alto nível excessivamente acadêmica. Os benefícios são que ele é rápido e eficiente e que eu posso realmente usar o RTFS se encontrar bugs ou comportamentos que não posso explicar. Também possibilita o uso em minúsculos 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 em tais sistemas em vez de ter que buscar a última fonte em outro lugar e rsync. / p>
Você pode estar interessado em ler por que o projeto GNOME do desktop escolheu o git over hg and bzr, quando ele decidiu migrar do svn alguns anos atrás. Houve muitas discussões religiosas acaloradas ao longo do caminho, é claro, mas esta página do GNOME Wiki resume bem os prós e contras quando se aplicaram a essa comunidade particular.
Sem mencionar que a Apple agora se envolveu em empurrá-lo para a comunidade c do objetivo, se você criou um novo aplicativo no Xcode 4 recentemente, você teria notado que ele automaticamente pergunta se você gostaria de fazer um Git repo.
Concedido que o Xcode 4 só existe há alguns meses e não influencia no sucesso anterior do Gits, mas todos sabemos como a Apple pode fazer coisas em um curto espaço de tempo.
Eu estou atualmente mudando de hg (kiln) para git (github). Eu usei forno por cerca de um ano agora. Para mim o hg não tem nenhuma desvantagem. Eu posso fazer tudo que preciso. Então é ótimo.
Por que estou usando agora?
Existem apenas três razões no momento.
Eu acho que o terceiro é o mais importante.
Thorsten
pura sorte eu acho, até agora quase impossível provar por que algo funcionou e outro não. Linus pode construir algo mais espetacular e não ter sucesso.
Tags git version-control mercurial