Qual é a diferença entre Mercurial e Git?

Trabalho na Mercurial, mas, fundamentalmente, acredito que ambos os sistemas são equivalentes. Ambos trabalham com as mesmas abstrações: uma série de instantâneos (changesets) que compõem a história. Cada changeset sabe de onde veio (o parent changeset) e pode ter muitas crianças changesets. A recente extensão HG-git fornece uma ponte bidirecional entre Mercurial e Git e mostra este ponto.

O Git tem um forte foco em Alterar este gráfico de história (com todo o consequências que isso implica) enquanto Mercurial não encoraja a reescrita da história, {[[11]} mas é fácil de fazer de qualquer maneira {[[[8]} e as consequências de fazê-lo são exatamente o que você deve esperar que eles sejam (isto é, se eu modificar um changeset que você já tem, seu cliente vai vê-lo como novo se você puxar de mim). Então Mercurial tem um viés para comandos não destrutivos.

Quanto aos ramos leves, a Mercurial suportou repositórios com múltiplos ramos desde... sempre penso. Repositórios Git com múltiplos ramificações são exatamente isso: múltiplas linhas divergentes de desenvolvimento em um único repositório. Git então adiciona nomes a esses fios e permite que você consulta esses nomes remotamente. A extensão dos favoritos para o Mercurial adiciona nomes locais e, com o Mercurial 1.6, poderá mover estes favoritos quando carregar/puxar..

Eu uso o Linux, mas aparentemente o TortoiseHg é mais rápido e melhor do que o equivalente Git no Windows (devido ao melhor uso do sistema de arquivos do Windows pobre). Ambos http://github.com e http://bitbucket.org fornecer hospedagem on-line, o serviço em Bitbucket é grande e responsivo (eu não tentei github).

Eu escolhi Mercurial uma vez que se sente limpo e elegante -- eu fui adiado pelos scripts shell/Perl/Ruby que eu tenho com o Git. Tente dar uma olhada no git-instaweb.sh file se quiser saber o que quero dizer: é um script shell que gera um script Ruby , que acho que tem um servidor web. O script shell gera outro script shell para lançar o primeiro script Ruby. Há também um pouco de Perl , para boa medida.

Gosto do post no blog que compara o Mercurial e o Git com o James Bond e o MacGyver.o Mercurial é mais discreto do que o Git. Parece-me que as pessoas que usam o Mercurial não se impressionam tão facilmente. Isto se reflete em como cada sistema faz o que Linus descreveu como " a fusão mais legal de sempre!". No Git, poderá juntar-se a 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-me bastante Arcanos aos olhos. Em Mercurial nós fazemos:

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

Repare como os comandos mercuriais são simples e não são especiais de todo -- a única coisa incomum é a bandeira --force para hg pull, que é necessária uma vez que a Mercurial irá abortar caso contrário quando você puxar de um repositório não relacionado. São diferenças como esta que fazem a Mercurial parecer mais elegante para mim.

O Git é uma plataforma, o Mercurial é "apenas" uma aplicação. Git é uma plataforma versionada de Sistema de arquivos que acontece com um aplicativo DVCS na caixa, mas como normal para aplicativos de plataforma, é mais complexo e tem arestas mais ásperas do que aplicativos focados fazem. Mas isso também significa que os VCS do git são imensamente flexíveis, e há uma enorme profundidade de coisas de controle Não-fonte que você pode fazer com o git.

Essa é a essência da diferença.

O Git é melhor entendido desde o início-a partir do formatação do repositório. A conversa Git de Scott Chacon é uma excelente iniciadora para isto. Se você tentar usar o git sem saber o que está acontecendo sob o capô, você vai acabar confuso em algum momento (a menos que você se cingir apenas a funcionalidade muito básica). Isto pode parecer estúpido quando tudo o que você quer é um DVCS para sua rotina de programação diária, mas o gênio do git é que o formato do repositório é realmente muito simples e você Pode entender toda a operação do git muito facilmente.

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

• As Diferenças entre Mercurial e Git
• fio Reddit onde Dustin experiente em git responde às suas próprias perguntas de neophyte.

Ele realmente usou ambos os DVCSs extensivamente e entende ambos bem-e acabou preferindo git.

A grande diferença está no Windows. O Mercurial é suportado nativamente, o Git não é. poderá obter uma hospedagem muito semelhante ao github.com com bitbucket.org (Na verdade, ainda melhor quando você recebe um repositório privado gratuito). Eu estava usando msysGit por um tempo, mas mudou-se para Mercurial e foi muito feliz com isso.

Se é um programador do Windows à procura do controlo básico de revisão desligado, vá com o Hg. Eu achei o Git incompreensível, enquanto o Hg era simples e bem integrado com o shell do Windows. Eu baixei o Hg e segui este tutorial (hginit.com dez minutos depois tive um acordo local e voltei a trabalhar no meu projecto.

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

"Git é Wesley Snipes. Mercurial é Denzel Washington"

São quase idênticas. A diferença mais importante, do meu ponto de vista (quero dizer, a razão que me levou a escolher um DVCS sobre o outro) é como os dois programas gerem filiais.

Para iniciar um novo ramo, com o Mercurial, basta clonar o repositório para outro directório e começar a desenvolver. Depois, puxas e FUNDES-te. Com o git, você tem que dar explicitamente um nome para o novo ramo tópico que você deseja usar, então você começa a codificar usando o mesmo directory .

Em resumo, cada ramo da Mercurial necessita do seu próprio directório; no git você normalmente trabalha em um único directório. Mudar de ramos no Mercurial significa mudar de diretórios; no git, significa pedir ao git para mudar o conteúdo do Diretório com a checkout do git.

Eu sou honesto: eu não sei se é possível fazer o mesmo com a Mercurial, mas como eu geralmente trabalho em projetos web, usando sempre o mesmo diretório com git parece-me muito confortável, uma vez que eu não tenho que re-configurar o Apache e reiniciá-lo e eu não bagunço o meu sistema de arquivos toda vez que eu branch.

Editar: como o Deestan observou, o Hg tem ramificações nomeadas , que podem ser armazenadas num único repositório e permitir ao programador mudar de ramificações dentro da mesma cópia de trabalho. git branches are not exactly the same as Mercurial named branches, anyway: they are permanent and not throw away branches, like in git. Isso significa que se você usar um ramo nomeado para tarefas experimentais, mesmo se você decidir nunca fundir ele será armazenado no repositório. Essa é a razão pela qual a Hg encoraja a usar clones para tarefas experimentais e de curta duração e ramificações nomeadas para tarefas de longa duração, como para ramificações de lançamento.

A razão pela qual muitos utilizadores de Hg preferem clones sobre ramificação nomeada é muito mais social ou cultural do que Técnico. Por exemplo, com as últimas versões de Hg, é mesmo possível fechar um ramo nomeado e remover recursivamente metadados de changesets.

Do outro lado, git. convites para usar "ramificações nomeadas" que não são permanentes e não são armazenados como metadados em cada changeset. Do meu ponto de vista pessoal, então, o modelo do git está profundamente ligado ao conceito de ramos nomeados e troca entre um ramo e outro com o mesmo diretório; o hg pode fazer o mesmo com ramos nomeados, mas ainda assim incentiva o uso de clones, que eu pessoalmente não gosto muito.

Existe umaenorme diferença entregit emercurial ; a forma como o representa cada commit. git representa commits como instantâneos, enquanto mercurial Os representa como diffs.

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 estes commits estão longe. AFAIK, não há vantagem na abordagem da mercurial.

Nada. Ambos fazem o mesmo, ambos atuam da mesma forma. A única razão pela qual você deve escolher um sobre o outro é se você ajudar com um projeto que já usa um..

A outra razão possível para escolher uma é uma aplicação ou serviço que só suporta um do sistema.. Por exemplo, eu praticamente 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 entendo corretamente (e estou longe de ser um especialista em cada um), fundamentalmente cada um deles tem uma filosofia diferente. Usei a mercurial pela primeira vez durante 9 meses. Agora eu usei git para 6.

O Hg é um software de controlo de versões. O objetivo principal é rastrear versões de um software.

O Git é um sistema de ficheiros baseado no tempo. O objetivo é adicionar outra dimensão a um sistema de arquivos. A maioria tem arquivos e pastas, git adiciona tempo. Que acontece de trabalhar incrível como um VCS é um subproduto do seu design.

Na hg, há uma história de todo o projecto que está sempre a tentar manter. Por padrão, eu acredito que hg quer todas as mudanças 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 (ramos/cabeças) que determinam que conjunto desses objetos representam a árvore de arquivos em um estado particular. Ao empurrar ou puxar o git só envia os objectos necessários para os ramos em particular que você é empurrar ou puxar, que é um pequeno subconjunto de todos os objetos.

No que diz respeito ao git, não existe nenhum "projecto 1". Podias ter 50 projectos todos no mesmo repo e o git não se importaria. Cada um poderia ser gerido separadamente no mesmo Acordo de recompra e viver bem.

O conceito de sucursais da Hg é constituído por sucursais do projecto principal ou sucursais de sucursais, etc. Git não tem tal conceito. Um ramo no git é apenas um estado da árvore, tudo é um ramo no git. Que sucursal é oficial, atual, ou mais recente não tem significado no git. Não sei se isso fazia algum sentido. Se eu pudesse fazer desenhos hg poderia ficar 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 ramos a sair dela. Enquanto git pode fazer isso e muitas vezes as pessoas usá-lo dessa forma que não é imposta. 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 sequer faz sentido mostrar ramos em git. [11] uma coisa que é muito confusa para a discussão, git e mercurial ambos têm algo chamado de "branch", mas eles não são remotamente as mesmas coisas. Um ramo na mercurial surge quando há conflitos entre diferentes repos. Um ramo no git é aparentemente similar a um clone no hg. Mas um clone, embora possa dar um comportamento semelhante, não é definitivamente o mesmo. Considere-me a tentar isto em git vs hg usando o repo de crómio 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 o 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

Ambos são corridas quentes. Eu corri-os duas vezes e esta é a segunda corrida. o clone hg é o mesmo que o git-new-workdir. Ambos fazem uma nova pasta de trabalho quase como se tivesses escrito. Não é o mesmo que fazer um novo ramo no git. É muito mais pesado. Se há um verdadeiro equivalente de git se ramificar em hg, não sei o que é.

Eu entendo que em algum nível hg e git pode ser capaz de fazer coisas semelhantes. Se assim for, então há uma diferença ainda enorme no fluxo de trabalho que o levam a. No git, o fluxo de trabalho típico é criar um branch 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

Que acabou de criar três ramos, cada um baseado num ramo chamado Mestre. (Tenho certeza que há uma maneira de fazer essas linhas cada uma em vez de 2) Agora, para trabalhar num Que Eu apenas faço.

git checkout fix-game-save-bug

E começa a trabalhar. Commit things, etc. Mudar de ramos mesmo num projecto tão grande como o chrome quase instantâneo. Na verdade, não sei como fazer isso em hg. Não faz parte de nenhum tutorial que tenha lido. Uma outra grande diferença. O palco do Git. O Git tem esta ideia de palco. Pode pensar nisso como uma pasta escondida. Quando você commit você só commit o que está no palco, não as mudanças em sua árvore de trabalho. Isso pode parecer estranho. Se você quiser enviar todas as alterações na sua árvore de trabalho você faria git commit -a que adiciona todos os arquivos modificados para o estágio e, em seguida, commits o. Qual é o objectivo do palco? Você pode facilmente separar seus commits. Imagina que editaste o joypad.cpp e gamesave.cpp e você 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 até tem comandos para decidir quais linhas em particular no mesmo ficheiro que deseja copiar para o estágio, para que possa dividir esses commits também separadamente. Porque queres fazer isso? Porque como commits separados outros podem puxar apenas aqueles que eles querem ou se houve um problema eles podem reverter apenas o compromisso que tinha o problema.

Existe um gráfico de comparação dinâmica no versioncontrolblog, onde poderá comparar vários sistemas de controlo de versões diferentes.

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

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

É explicado neste artigo (ramificação explicada) que compara Mercurial com Git.

Há algum colaborador baseado no Windows no seu projecto? Porque se houver, a GUI Git-for-Windows parece estranha, difícil, hostil.

Mercurial-on-Windows, em contraste, é um sem-brainer.

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

Algures no ano passado, avaliei tanto o git como o hg para o meu próprio uso, e decidi escolher o hg. Eu senti que parecia uma solução mais limpa, e trabalhou melhor em mais plataformas na época. No entanto, foi quase tudo uma reviravolta.

Mais recentemente, comecei a usar o git por causa do git-svn e da capacidade de agir como um cliente Subversion. Isto convenceu-me e agora mudei completamente para o git. Eu acho que ele tem uma curva de aprendizagem um pouco mais alta (especialmente se você precisa bisbilhotar em torno do interior), mas é realmente um grande sistema. Vou ler aqueles dois artigos de comparação que o John postou agora.

Estou atualmente no processo de migração de SVN para um DVCS (enquanto blogando sobre minhas descobertas, meu primeiro esforço real de blogagem...), and i've done a bit of research (=Google). Tanto quanto eu posso ver você pode fazer a maioria das coisas com ambos os pacotes. Parece que o git tem algumas funcionalidades avançadas mais ou melhor implementadas, Eu sinto que a integração com windows é um pouco melhor para a mercurial, com TortoiseHg. Eu sei que há Git Cheetah também (eu tentei ambos), mas o mercurial a solução parece mais robusta.

Vendo como ambos são de código aberto (certo?) Eu não acho que nenhum dos dois estará faltando características importantes. Se algo é importante, as pessoas vão pedir, as pessoas vão codificá-lo. Acho que para as práticas comuns, O Git e o Mercurial são mais do que suficientes. Ambos têm grandes projetos que os usam (git - > linux kernel, Mercurial - > Mozilla foundation projects, ambos entre outros, é claro), então eu não acho que ambos estão realmente faltando algum. Dito isto, estou interessado no que as outras pessoas dizem sobre isso, pois seria uma grande fonte para meus esforços de blogagem; -)

Existe uma grande e exaustiva tabela de comparação e gráficos sobre git, Mercurial e Bazaar em O Guia do InfoQ sobre DVCS.

Eu percebo que esta não é uma parte da resposta, mas nessa nota, eu também acho que a disponibilidade de plugins estáveis para plataformas como NetBeans e Eclipse desempenhar um papel em que a ferramenta é um melhor ajuste para a tarefa, ou melhor, que a ferramenta é o melhor ajuste para "você". Isto é, a não ser que queiras mesmo fazê-lo à Maneira do CLI.

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

Também estou a tentar responder a esta pergunta.. e eu resumi os candidatos a Git ou Mercurial .. obrigado a todos por fornecerem contributos úteis sobre este tema sem se tornarem religiosos.

Outra comparação interessante de mercurial e git: Mercurial vs Git. O foco principal é nos internos e sua influência no processo de ramificação.

Se você está interessado em uma comparação de desempenho de Mercurial e Git dê uma olhada este artigo . A conclusão é:

O Git e o Mercurial transformam-se em bons números, mas fazem uma troca interessante entre a velocidade e o tamanho do repositório. A Mercurial é rápida com adições e modificações, e mantém o crescimento do repositório sob controle ao mesmo tempo. O Git também é rápido, mas o seu repositório cresce muito rapidamente com arquivos modificados até que você reack-e esses repacks pode ser muito lento. Mas o depósito embalado é muito menor que o do Mercurial.

O site mercurial tem uma grande Descrição das semelhanças e diferenças entre os dois sistemas, explicando as diferenças de vocabulário e conceitos subjacentes. Como um usuário git longo tempo, realmente ajudou-me a entender a mentalidade Mercurial.

Se estiver a migrar do SVN, use o Mercurial, uma vez que a sua sintaxe é muito mais compreensível para os utilizadores do SVN. Tirando isso, também não podes correr mal. Mas verifique o tutorial git e o HGinit antes de seleccionar um deles.

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

Algumas pessoas acham que os sistemas VCS têm de ser complicados. Eles incentivam a invenção de termos e conceitos no campo. Eles provavelmente pensam que numerosos PhDs sobre o assunto seria interessante. Entre eles estão provavelmente os que desenharam o Git. A Mercurial foi concebida com uma mentalidade diferente. Os desenvolvedores não devem se importar muito com VCS, e eles devem, em vez disso, gastar seu tempo em sua função principal: engenharia de software. A Mercurial permite que os usuários usem e se sintam felizes abusar do sistema sem deixá-los cometer quaisquer erros não recuperáveis.

Qualquer ferramenta profissional deve vir com um CLI claramente concebido e intuitivo. Os usuários da Mercurial podem fazer a maior parte do trabalho emitindo comandos simples sem quaisquer opções estranhas. Em git double dash, opções loucas são a norma. A Mercurial tem uma vantagem substancial se você é uma pessoa CLI (e para ser honesto, qualquer engenheiro de Software que se preze deve ser).

Para dar um exemplo, suponha que você faz um commit por erro. Esqueceu-se de editar alguns ficheiros. Para desfazer a sua acção na Mercurial, basta escrever:

$ hg rollback

Então, recebes uma mensagem de que o sistema anula a tua última transacção.

No Git tem de escrever:

$ git reset --soft HEAD^

Então, OK, suponha que você tem uma idéia sobre o que reset é. Mas, além disso, você tem que saber o que" --soft "e" -- hard " resets São (algum palpite intuitivo?). E, claro, não te esqueças da personagem no final! (agora o que em nome de Ritchie é que...) A integração da Mercurial com ferramentas de terceiros como o kdiff3 e o meld também é muito melhor. Gerar os seus 'patches' juntar os seus ramos sem muita confusão. O Mercurial também inclui um Servidor http simples que você ativa digitando

hg serve

E deixe que outros navegem no seu repositório.

A conclusão é que o Git faz o que o Mercurial faz, de uma forma muito mais complicada e com um CLI muito inferior. Use o Git se quiser transformar os VCS do seu projecto num campo de pesquisa científica. Use a Mercurial se você quiser obter o trabalho VCS feito sem se importar muito com ele, e se concentrar em suas tarefas reais.