Qual é a diferença entre Mercurial e Git?

StackOverflow https://stackoverflow.com/questions/35837

Pergunta

Já uso o git há algum tempo no Windows (com msysGit) e gosto da ideia de controle de origem distribuído.Recentemente estive olhando o Mercurial (hg) e parece interessante.No entanto, não consigo entender as diferenças entre hg e git.

Alguém fez uma comparação lado a lado entre git e hg?Estou interessado em saber o que difere hg e git sem ter que entrar em uma discussão de fanboy.

Foi útil?

Solução

Estes artigos podem ajudar:

Editar:Comparar Git e Mercurial com celebridades parece ser uma tendência.Aqui está mais um:

Outras dicas

Trabalho no Mercurial, mas fundamentalmente acredito que os dois sistemas são equivalentes.Ambos trabalham com as mesmas abstrações:uma série de instantâneos (changesets) que compõem o histórico.Cada conjunto de alterações sabe de onde veio (o conjunto de alterações pai) e pode ter muitos conjuntos de alterações filhos.O recente hg-git extension fornece uma ponte bidirecional entre Mercurial e Git e meio que mostra esse ponto.

O Git tem um forte foco na mutação deste gráfico histórico (com todas as consequências que isso acarreta), enquanto o Mercurial não incentiva a reescrita do histórico, mas é fácil de fazer de qualquer maneira e as consequências de fazer isso são exatamente o que você espera que sejam (ou seja, se eu modificar um conjunto de alterações que você já possui, seu cliente o verá como novo se você extrair de mim).Então Mercurial tem um viés em direção a comandos não destrutivos.

Quanto às ramificações leves, o Mercurial oferece suporte a repositórios com múltiplas filiais desde..., sempre penso.Repositórios Git com múltiplas ramificações são exatamente isso:múltiplas vertentes divergentes de desenvolvimento em um único repositório.O Git então adiciona nomes a essas vertentes e permite que você consulte esses nomes remotamente.O Favoritos A extensão para Mercurial adiciona nomes locais e, com o Mercurial 1.6, você pode mover esses marcadores ao empurrar/puxar.

Eu uso Linux, mas aparentemente o TortoiseHg é mais rápido e melhor que o equivalente Git no Windows (devido ao melhor uso do fraco sistema de arquivos do Windows).Ambos http://github.com e http://bitbucket.org fornecer hospedagem online, o serviço do Bitbucket é ótimo e responsivo (não experimentei o github).

Eu escolhi o Mercurial porque parece limpo e elegante - fiquei desanimado com os scripts Shell/Perl/Ruby que recebi com o Git.Experimente dar uma olhada no git-instaweb.sh arquivo se você quiser saber o que quero dizer:é um concha script que gera um Rubi script, que eu acho que executa um servidor web.O script shell gera outro script shell para iniciar o primeiro script Ruby.Há também um pouco de Perl, para garantir.

eu gosto de postagem no blog que compara Mercurial e Git com James Bond e MacGyver - Mercurial é de alguma forma mais discreto que Git.Parece-me que as pessoas que usam o Mercurial não se impressionam tão facilmente.Isso se reflete na forma como cada sistema faz o que Linus descreveu como "a fusão mais legal de SEMPRE!".No Git você pode mesclar com um repositório não relacionado fazendo:

git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit

Esses comandos parecem bastante misteriosos aos meus olhos.No Mercurial fazemos:

hg pull --force <project-to-union-merge>
hg merge
hg commit

Observe como os comandos do Mercurial são simples e nada especiais - a única coisa incomum é o --force bandeira para hg pull, o que é necessário, pois o Mercurial será abortado quando você extrair de um repositório não relacionado.São diferenças como essa que fazem o Mercurial parecer mais elegante para mim.

Git é uma plataforma, Mercurial é “apenas” um aplicativo.Git é uma plataforma de sistema de arquivos versionada que vem com um aplicativo DVCS na caixa, mas como é normal para aplicativos de plataforma, é mais complexo e tem arestas mais ásperas do que os aplicativos focados.Mas isso também significa que o VCS do git é imensamente flexível e há uma enorme profundidade de coisas sem controle de origem que você pode fazer com o git.

Essa é a essência da diferença.

O Git é melhor compreendido desde o início – desde o formato do repositório. Git Talk de Scott Chacon é uma excelente cartilha para isso.Se você tentar usar o git sem saber o que está acontecendo nos bastidores, você acabará confuso em algum momento (a menos que se atenha apenas a funcionalidades muito básicas).Isso pode parecer estúpido quando tudo o que você deseja é um DVCS para sua rotina diária de programação, mas a genialidade do git é que o formato do repositório é na verdade muito simples e você pode entenda toda a operação do git com bastante facilidade.

Para algumas comparações mais tecnicistas, os melhores artigos que vi pessoalmente são os de Dustin Sallings:

Na verdade, ele usou ambos os DVCS extensivamente e os entende bem – e acabou preferindo o git.

A grande diferença está no Windows.O Mercurial é suportado nativamente, o Git não.Você pode obter hospedagem muito semelhante a github.com com bitbucket.org (na verdade, ainda melhor quando você obtém um repositório privado gratuito).Eu estava usando o msysGit por um tempo, mas mudei para o Mercurial e fiquei muito feliz com ele.

Se você é um desenvolvedor do Windows em busca de controle básico de revisão desconectado, escolha Hg.Achei o Git incompreensível, enquanto o Hg era simples e bem integrado ao shell do Windows.Baixei o Hg e segui este tutorial (hginit.com) - dez minutos depois eu tinha um repositório local e voltei a trabalhar no meu projeto.

Acho que a melhor descrição sobre “Mercurial vs.Git" é:

"O idiota é Wesley Snipes.Mercurial é Denzel Washington"

Eles são quase idênticos.A diferença mais importante, do meu ponto de vista (quero dizer, a razão que me levou a escolher um DVCS em vez do outro) é como os dois programas gerenciam as filiais.

Para iniciar um novo branch, com o Mercurial, basta clonar o repositório para outro diretório e comece a desenvolver.Então, você puxa e mescla.Com o git, você precisa dar explicitamente um nome ao novo ramo de tópico que deseja usar e, em seguida, começar a codificar usando o mesmo diretório.

Resumindo, cada branch do Mercurial precisa de seu próprio diretório;no git você geralmente trabalha em um único diretório.Mudar de branch no Mercurial significa mudar de diretório;no git, significa pedir ao git para alterar o conteúdo do diretório com git checkout.

Eu sou honesto:Não sei se é possível fazer o mesmo com o Mercurial, mas como costumo trabalhar em projetos web, usar sempre o mesmo diretório com o git me parece muito confortável, já que não preciso reconfigurar o Apache e reiniciar isso e não bagunço meu sistema de arquivos toda vez que ramifico.

Editar:Como Deestan observou, Hg tem ramos nomeados, que pode ser armazenado em um único repositório e permitir ao desenvolvedor alternar ramificações dentro da mesma cópia de trabalho.De qualquer forma, as ramificações git não são exatamente iguais às ramificações nomeadas do Mercurial:eles são permanentes e não jogam fora galhos, como no git.Isso significa que se você usar um branch nomeado para tarefas experimentais, mesmo que decida nunca mesclá-lo, ele será armazenado no repositório.Essa é a razão pela qual Hg incentiva o uso de clones para tarefas experimentais de curta duração e ramificações nomeadas para tarefas de longa execução, como ramificações de lançamento.

A razão pela qual muitos usuários de Hg preferem clones a ramificações nomeadas é muito mais social ou cultural do que técnica.Por exemplo, com as últimas versões do Hg, é até possível fechar uma ramificação nomeada e remover recursivamente os metadados dos conjuntos de alterações.

Por outro lado, o git convida a usar "ramificações nomeadas" que não são permanentes e não são armazenadas como metadados em cada conjunto de alterações.

Do meu ponto de vista pessoal, então, o modelo do git está profundamente ligado ao conceito de ramificações nomeadas e à alternância entre uma ramificação e outra dentro do mesmo diretório;hg pode fazer o mesmo com ramificações nomeadas, mas ainda assim incentiva o uso de clones, dos quais eu pessoalmente não gosto muito.

Há uma enorme diferença entre idiota e mercurial;a maneira como representam cada commit. idiota representa commits como instantâneos, enquanto mercurial representa-os como diferenças.

O que isso significa na prática?Bem, muitas operações são mais rápidas no git, como mudar para outro commit, comparar commits, etc.Especialmente se esses commits estiverem distantes.

AFAIK, não há vantagem na abordagem do Mercurial.

Nada.Ambos fazem o mesmo, ambos têm desempenho quase igual.A única razão pela qual você deve escolher um em vez do outro é se você ajudar em um projeto que já utiliza um.

A outra razão possível para escolher um é um aplicativo ou serviço que suporta apenas um dos sistemas.Por exemplo, eu escolhi aprender git por causa de GitHub..

Também a comparação do Google (embora seja um pouco antiga, feita em 2008)

http://code.google.com/p/support/wiki/DVCSAnalysis

Se eu os entendi corretamente (e estou longe de ser um especialista em cada um deles), cada um deles fundamentalmente tem uma filosofia diferente.Usei o Mercurial pela primeira vez por 9 meses.Agora usei o git por 6.

hg é um software de controle de versão.Seu principal objetivo é rastrear versões de um software.

git é um sistema de arquivos baseado em tempo.Seu objetivo é adicionar outra dimensão a um sistema de arquivos.A maioria possui arquivos e pastas, o git adiciona tempo.O fato de funcionar muito bem como um VCS é um subproduto de seu design.

No hg, há um histórico de todo o projeto que ele está sempre tentando manter.Por padrão, acredito que hg deseja todas as alterações em todos os objetos por todos os usuários ao empurrar e puxar.

No git há apenas um conjunto de objetos e esses arquivos de rastreamento (branches/heads) que determinam qual conjunto desses objetos representa a árvore de arquivos em um determinado estado.Ao empurrar ou puxar, o git envia apenas os objetos necessários para os ramos específicos que você está empurrando ou puxando, que é um pequeno subconjunto de todos os objetos.

No que diz respeito ao git, não existe "1 projeto".Você poderia ter 50 projetos no mesmo repositório e o git não se importaria.Cada um pode ser gerenciado separadamente no mesmo repositório e funcionar bem.

O conceito de ramificações de Hg é ramificar o projeto principal ou ramificar ramificações, etc.Git não tem esse conceito.Um branch no git é apenas um estado da árvore, tudo é um branch no git.Qual branch é oficial, atual ou mais novo não tem significado no git.

Não sei se isso fazia algum sentido.Se eu pudesse fazer desenhos, hg ficaria assim, onde cada commit é um o

             o---o---o
            /        
o---o---o---o---o---o---o---o
         \         /
          o---o---o

Uma árvore com uma única raiz e galhos saindo dela.Embora o git possa fazer isso e muitas vezes as pessoas o usem dessa forma, isso não é obrigatório.Uma imagem git, se existe tal coisa, poderia facilmente ser assim

o---o---o---o---o

o---o---o---o
         \
          o---o

o---o---o---o

Na verdade, de certa forma, nem faz sentido mostrar ramificações no git.

Uma coisa que é muito confusa para a discussão, git e mercurial têm algo chamado de "branch", mas não são nem remotamente a mesma coisa.Uma ramificação no Mercurial surge quando há conflitos entre diferentes repositórios.Uma ramificação no git é aparentemente semelhante a um clone no hg.Mas um clone, embora possa apresentar um comportamento semelhante, definitivamente não é o mesmo.Considere-me tentar isso no git vs hg usando o repositório chromium, que é bastante grande.

$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'

real   0m1.759s
user   0m1.596s
sys    0m0.144s

E agora em hg usando clone

$ time hg clone project/ some-clone/

updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real   0m58.196s
user   0m19.901s
sys    0m8.957

Ambas são corridas quentes.Ou seja, eu os executei duas vezes e esta é a segunda execução.hg clone é na verdade igual a git-new-workdir.Ambos criam um diretório de trabalho totalmente novo, quase como se você tivesse digitado cp -r project project-clone.Isso não é o mesmo que criar um novo branch no git.É muito mais pesado.Se existe um equivalente verdadeiro da ramificação do git em hg, não sei o que é.

Eu entendo em algum nível hg e git poder ser capaz de fazer coisas semelhantes.Nesse caso, ainda há uma grande diferença no fluxo de trabalho para o qual eles o conduzem.No git, o fluxo de trabalho típico é criar uma ramificação para cada recurso. 

git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support

Isso acabou de criar 3 ramificações, cada uma baseada em uma ramificação chamada master.(Tenho certeza de que há alguma maneira no git de criar 1 linha cada em vez de 2)

Agora, para trabalhar em um, eu simplesmente faço

git checkout fix-game-save-bug

e comece a trabalhar.Comprometer coisas, etc.Alternar entre ramificações, mesmo em um projeto tão grande quanto o Chrome, é quase instantâneo.Na verdade, não sei como fazer isso em hg.Não faz parte de nenhum tutorial que li.

Outra grande diferença.O palco do Git.

Git tem essa ideia de palco.Você pode pensar nisso como uma pasta oculta.Ao confirmar, você confirma apenas o que está no palco, não as alterações na sua árvore de trabalho.Isso pode parecer estranho.Se você quiser confirmar todas as alterações na sua árvore de trabalho, você faria git commit -a que adiciona todos os arquivos modificados ao palco e depois os confirma.

Qual é o objetivo do palco então?Você pode facilmente separar seus commits.Imagine que você editou joypad.cpp e gamesave.cpp e deseja enviá-los separadamente

git add joypad.cpp  // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp  // copies to stage
git commit -m "fixed game save bug"

O Git ainda possui comandos para decidir quais linhas específicas do mesmo arquivo você deseja copiar para o palco, para que você também possa dividir esses commits separadamente.Por que você gostaria de fazer isso?Porque como commits separados, outros podem extrair apenas aqueles que desejam ou, se houver um problema, eles podem reverter apenas o commit que apresentou o problema.

Há um gráfico de comparação dinâmica no versioncontrolblog onde você pode comparar vários sistemas de controle de versão diferentes.

Aqui está uma tabela de comparação entre git, hg e bzr.

Existem diferenças bastante significativas quando se trata de trabalhar com filiais (principalmente as de curto prazo).

Está explicado em este artigo (ramificação explicada) que compara o Mercurial com o Git.

Há algum colaborador baseado em Windows em seu projeto?

Porque se houver, a GUI do Git para Windows parece estranha, difícil e hostil.

O Mercurial-on-Windows, por outro lado, é óbvio.

Uma coisa a se notar entre o mercurial do bitbucket.org e o git do github é que o mercurial pode ter quantos repositórios privados você quiser, mas no github você precisa atualizar para uma conta paga.Então é por isso que optei pelo bitbucket que usa mercurial.

Em algum momento do ano passado, avaliei o git e o hg para meu próprio uso e decidi usar o hg.Achei que parecia uma solução mais limpa e funcionava melhor em mais plataformas na época.No entanto, foi principalmente uma disputa.

Mais recentemente, comecei a usar o git por causa do git-svn e da capacidade de atuar como um cliente Subversion.Isso me conquistou e agora mudei completamente para o git.Acho que tem uma curva de aprendizado um pouco mais alta (especialmente se você precisar fuçar no interior), mas é realmente um ótimo sistema.Vou ler aqueles dois artigos comparativos que John postou agora.

Atualmente estou no processo de migração de SVN para um DVCS (enquanto blogava sobre minhas descobertas, meu primeiro esforço real de blog...) e fiz algumas pesquisas (= pesquisando no Google).Pelo que posso ver, você pode fazer a maioria das coisas com os dois pacotes.Parece que o Git tem alguns recursos avançados mais ou melhor implementados, sinto que a integração com o Windows é um pouco melhor para o Mercurial, com o TortoiseHG.Eu sei que também existe o Git Cheetah (tentei os dois), mas a solução mercurial parece mais robusta.

Vendo como ambos são de código aberto (certo?), não acho que nenhum deles careça de recursos importantes.Se algo é importante, as pessoas vão pedir, vão codificar.

Acho que para práticas comuns, Git e Mercurial são mais que suficientes.Ambos têm grandes projetos que os utilizam (Git -> kernel Linux, Mercurial -> projetos de fundação Mozilla, ambos entre outros, é claro), então não acho que esteja realmente faltando alguma coisa.

Dito isto, estou interessado no que outras pessoas dizem sobre isso, pois seria uma ótima fonte para meus esforços de blog ;-)

Há tabelas e gráficos de comparação excelentes e exaustivos sobre git, Mercurial e Bazaar em Guia do InfoQ sobre DVCS.

Sei que isso não faz parte da resposta, mas, por falar nisso, também acho que a disponibilidade de plug-ins estáveis ​​para plataformas como NetBeans e Eclipse desempenha um papel importante na escolha de qual ferramenta é mais adequada para a tarefa, ou melhor, qual ferramenta é a melhor opção para "você".Isto é, a menos que você realmente quero fazer isso do jeito CLI.

Tanto o Eclipse (e tudo baseado nele) quanto o NetBeans às vezes apresentam problemas com sistemas de arquivos remotos (como SSH) e atualizações externas de arquivos;que é mais uma razão pela qual você deseja que tudo o que escolher funcione "perfeitamente".

Estou tentando responder a essa pergunta para mim também agora.e resumi os candidatos ao Git ou Mercurial.obrigado a todos por fornecerem informações úteis sobre este tópico sem se tornarem religiosos.

Mais uma comparação interessante entre mercurial e git: Mercúrio versus Git.O foco principal está nos internos e sua influência no processo de ramificação.

Se você estiver interessado em uma comparação de desempenho do Mercurial e do Git, dê uma olhada em Este artigo.A conclusão é:

Git e Mercurial apresentam bons números, mas fazem uma troca interessante entre velocidade e tamanho do repositório.O Mercurial é rápido com adições e modificações e, ao mesmo tempo, mantém o crescimento do repositório sob controle.O Git também é rápido, mas seu repositório cresce muito rapidamente com arquivos modificados até você reempacotar — e esses reempacotamentos podem ser muito lentos.Mas o repositório compactado é muito menor que o do Mercurial.

O site mercurial tem um ótima descrição das semelhanças e diferenças entre os dois sistemas, explicando as diferenças de vocabulário e conceitos subjacentes.Como usuário git de longa data, isso realmente me ajudou a entender a mentalidade do Mercurial.

Se você estiver migrando do SVN, use o Mercurial, pois sua sintaxe é MUITO mais compreensível para usuários do SVN.Fora isso, você não pode errar com nenhum dos dois.Mas verifique Tutorial do GIT e HGinit antes de selecionar um deles.

Este link pode ajudá-lo a entender a diferençahttp://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/

Algumas pessoas pensam que os sistemas VCS precisam ser complicados.Eles incentivam a invenção de termos e conceitos na área.Eles provavelmente pensariam que vários PhDs sobre o assunto seriam interessantes.Entre eles estão provavelmente aqueles que projetaram o Git.

Mercurial foi projetado com uma mentalidade diferente.Os desenvolvedores não devem se preocupar muito com o VCS e, em vez disso, devem dedicar seu tempo à sua função principal:Engenharia de software.O Mercurial permite que os usuários usem e abusem do sistema com alegria, sem permitir que cometam erros irrecuperáveis.

Qualquer ferramenta profissional deve vir com uma CLI intuitiva e claramente projetada.Os usuários do Mercurial podem fazer a maior parte do trabalho emitindo comandos simples, sem opções estranhas.No Git double dash, opções malucas são a norma.O Mercurial tem uma vantagem substancial se você é uma pessoa CLI (e para ser honesto, qualquer engenheiro de software que se preze deveria ser).

Para dar um exemplo, suponha que você faça um commit por engano.Você esqueceu de editar alguns arquivos.Para desfazer sua ação no Mercurial basta digitar:

$ hg rollback

Você então receberá uma mensagem informando que o sistema desfaz sua última transação.

No Git você deve digitar:

$ git reset --soft HEAD^

Então, ok, suponha que você tenha uma ideia do que se trata a redefinição.Mas, além disso, você precisa saber o que são redefinições "--soft" e "-hard" (alguma suposição intuitiva?).Ah, e claro, não se esqueça do caractere '^' no final!(agora o que em nome de Ritchie é isso...)

A integração do Mercurial com ferramentas de terceiros como kdiff3 e meld também é muito melhor.Gere seus patches e mescle seus ramos sem muito barulho.O Mercurial também inclui um servidor http simples que você ativa digitando

hg serve

E deixe que outras pessoas naveguem em seu repositório.

O resultado final é que o Git faz o que o Mercurial faz, de uma forma muito mais complicada e com uma CLI muito inferior.Use Git se quiser transformar o VCS do seu projeto em um campo de pesquisa científica.Use o Mercurial se quiser realizar o trabalho do VCS sem se preocupar muito com isso e focar em suas tarefas reais.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top