Estou usando o git há algum tempo no Windows (com msysGit) e gosto da ideia de controle de fonte 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 precisar entrar em uma discussão de fãs.
Respostas:
Estes artigos podem ajudar:
Edit : Comparando Git e Mercurial para celebridades parece ser uma tendência. Aqui está mais um:
Eu trabalho no Mercurial, mas fundamentalmente acredito que ambos os sistemas são equivalentes. Ambos trabalham com as mesmas abstrações: uma série de instantâneos (conjuntos de alterações) 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 filho. A recente extensão hg-git fornece uma ponte de mão dupla entre Mercurial e Git e mostra esse ponto.
O Git tem um forte foco em alterar esse gráfico de histórico (com todas as consequências), enquanto o Mercurial não incentiva a reescrita do histórico, mas é fácil fazer assim mesmo e as consequências de fazer isso são exatamente o que você deveria esperar (isto é, , se eu modificar um conjunto de alterações que você já possui, seu cliente o verá como novo se você retirar de mim). Portanto, o Mercurial tem um viés em relação a comandos não destrutivos.
Quanto a ramificações leves, o Mercurial suporta repositórios com várias ramificações desde ..., sempre acho. Os repositórios Git com várias ramificações são exatamente isso: várias vertentes de desenvolvimento divergentes em um único repositório. O Git adiciona nomes a esses strands e permite que você consulte esses nomes remotamente. A extensão Bookmarks para Mercurial adiciona nomes locais e, com o Mercurial 1.6, você pode mover esses indicadores ao pressionar / puxar.
Eu uso o Linux, mas aparentemente o TortoiseHg é mais rápido e melhor do que o equivalente ao Git no Windows (devido ao melhor uso do sistema de arquivos ruim do Windows). Tanto o http://github.com como o http://bitbucket.org oferecem hospedagem on-line, o serviço do Bitbucket é ótimo e responsivo (eu não tentei o github).
Eu escolhi o Mercurial, pois ele é limpo e elegante - fiquei impressionado com os scripts shell / Perl / Ruby que obtive com o Git. Tente dar uma olhada no git-instaweb.sharquivo, se você quiser saber o que quero dizer: é um script de shell que gera um script Ruby , que eu acho que executa um servidor da web. O script shell gera outro script shell para iniciar o primeiro script Ruby. Há também um pouco de Perl , para uma boa medida.
Gosto da postagem do blog que compara Mercurial e Git com James Bond e MacGyver - o Mercurial é, de certa forma, mais discreto que o Git. Parece-me que as pessoas que usam o Mercurial não são tão facilmente impressionadas. Isso se reflete em como cada sistema faz o que Linus descreveu como "a mesclagem mais legal de todos os tempos!" . 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. Na 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 é a --forcebandeira hg pull, o que é necessário, pois o Mercurial será interrompido caso contrário, quando você puxa de um repositório não relacionado. São diferenças como essa que fazem o Mercurial parecer mais elegante para mim.
git pull <url-of-project>. o e-mail que você citou é dos primórdios do git (2005)
Git é uma plataforma, o Mercurial é "apenas" um aplicativo. O Git é uma plataforma de sistema de arquivos com versão que é fornecida com um aplicativo DVCS na caixa, mas, como normal para aplicativos de plataforma, é mais complexa 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 que não podem ser controladas por fontes que você pode fazer com o git.
Essa é a essência da diferença.
O Git é melhor compreendido desde o início - a partir do formato do repositório. O Git Talk de Scott Chacon é um excelente manual para isso. Se você tentar usar o git sem saber o que está acontecendo sob o capô, você ficará confuso em algum momento (a menos que atenha apenas às funcionalidades básicas). Isso 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 com bastante facilidade.
Para algumas comparações mais orientadas para a tecnicidade, os melhores artigos que eu pessoalmente vi são de Dustin Sallings:
Na verdade, ele usou os dois DVCSs 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 ao github.com com o bitbucket.org (na verdade, ainda melhor quando você obtém um repositório privado gratuito). Eu estava usando o msysGit por um tempo, mas fui para o Mercurial e fiquei muito feliz com isso.
Se você é um desenvolvedor de Windows que procura um controle de revisão desconectado básico, vá com Hg. Achei o Git incompreensível, enquanto o Hg era simples e bem integrado ao shell do Windows. Fiz o download do Hg e segui este tutorial (hginit.com) - dez minutos depois, tive um repositório local e voltei a trabalhar no meu projeto.
Eu acho que a melhor descrição sobre "Mercurial vs. Git" é:
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 detrimento do outro) é como os dois programas gerenciam filiais.
Para iniciar uma nova ramificação, com o Mercurial, basta clonar o repositório em outro diretório e começar a desenvolver. Então, você puxa e funde. Com o git, é necessário dar um nome explícito ao novo ramo de tópico que você deseja usar e começar a codificar usando o mesmo diretório .
Em resumo, cada filial do Mercurial precisa de seu próprio diretório; no git você costuma trabalhar em um único diretório. Trocar ramificações no Mercurial significa mudar de diretório; no git, significa pedir ao git para alterar o conteúdo do diretório com o git checkout.
Eu sou honesto: não sei se é possível fazer o mesmo com o Mercurial, mas como eu geralmente trabalho em projetos da web, usar sempre o mesmo diretório com o git parece muito confortável para mim, pois não preciso -configure o Apache e reinicie-o e eu não mexo no meu sistema de arquivos toda vez que eu ramifico.
Edit: Como Deestan observou, Hg nomeou branches , que podem ser armazenados em um único repositório e permitem que o desenvolvedor alterne ramos dentro da mesma cópia de trabalho. galhos git não são exatamente iguais aos galhos chamados Mercurial, de qualquer maneira: são permanentes e não jogam fora galhos, como no git. Isso significa que, se você usar uma ramificação nomeada para tarefas experimentais, mesmo que decida nunca mesclá-la, ela será armazenada no repositório. Essa é a razão pela qual o Hg incentiva o uso de clones para tarefas experimentais de execução curta e ramificações nomeadas para tarefas de longa execução, como para ramificações de lançamento.
A razão pela qual muitos usuários de Hg preferem clones ao invés de ramificações nomeadas é muito mais social ou cultural do que técnica. Por exemplo, nas últimas versões do Hg, é possível fechar uma ramificação nomeada e remover metadados recursivamente 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, o modelo do git está profundamente vinculado ao conceito de ramificações nomeadas e alterna entre uma ramificação e outra dentro do mesmo diretório; O hg pode fazer o mesmo com os ramos nomeados, mas ainda assim incentiva o uso de clones, dos quais eu pessoalmente não gosto muito.
Há uma enorme diferença entre git e mercurial ; a maneira como representam cada commit. git representa commit como snapshots, 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 alternar para outro commit, comparar confirmações, etc. Especialmente se essas confirmações estiverem distantes.
AFAIK não há vantagem na abordagem do mercurial.
Nada. Ambos fazem o mesmo, ambos têm o mesmo desempenho. 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 um é um aplicativo ou serviço que suporta apenas um dos sistemas. Por exemplo, eu escolhi aprender o git por causa do github .
Também a comparação do Google (embora seja um pouco antiga, feita em 2008)
Se os entendi corretamente (e estou longe de ser um especialista em cada um), eles fundamentalmente têm uma filosofia diferente. Eu usei o mercurial pela primeira vez por 9 meses. Agora eu usei o git para 6.
hg é um software de controle de versão. Seu principal objetivo é rastrear versões de um software.
O git é um sistema de arquivos baseado em tempo. Seu objetivo é adicionar outra dimensão a um sistema de arquivos. A maioria tem arquivos e pastas, o git adiciona tempo. O fato de funcionar de maneira impressionante como um VCS é um subproduto de seu design.
Em hg, há um histórico de todo o projeto que ele está sempre tentando manter. Por padrão, acredito que o hg deseja todas as alterações em todos os objetos por todos os usuários ao pressionar e puxar.
No git, há apenas um conjunto de objetos e esses arquivos de rastreamento (ramificações / cabeças) que determinam qual conjunto desses objetos representa a árvore de arquivos em um estado específico. 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 há "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 viver bem.
O conceito de Hg de ramificações é ramificações do projeto principal ou ramificações etc. O Git não tem esse conceito. Um ramo no git é apenas um estado da árvore, tudo é um ramo no git. Qual ramo é oficial, atual ou mais recente não tem significado no git.
Não sei se isso faz algum sentido. Se eu pudesse desenhar imagens, o hg pode ficar assim em que cada commit é umo
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
Uma árvore com uma única raiz e galhos saindo dela. Enquanto o git pode fazer isso, e muitas vezes as pessoas usam dessa maneira que não são aplicadas. Uma imagem do Git, se houver, poderia facilmente se parecer com isso
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
De fato, 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 "ramo", mas não são remotamente as mesmas coisas. Um ramo no mercurial ocorre quando há conflitos entre diferentes repositórios. Uma ramificação no git é aparentemente semelhante a um clone em hg. Mas um clone, embora possa dar um comportamento semelhante, definitivamente não é o mesmo. Considere-me tentar isso no git vs hg usando o repositório de cromo, 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
Ambos são corridas quentes. Ou seja, eu os executei duas vezes e esta é a segunda execução. O clone hg é o mesmo que o git-new-workdir. Ambos formam 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 ramo no git. É muito mais pesado. Se existe o equivalente verdadeiro da ramificação do git em hg, não sei o que é.
Eu entendo que, em algum nível, hg e git possam fazer coisas semelhantes. Nesse caso, ainda existe uma grande diferença no fluxo de trabalho para o qual eles levam. 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 três ramificações, cada uma baseada em uma ramificação chamada mestre. (Tenho certeza de que há alguma maneira no git de fazer essas 1 linha cada em vez de 2)
Agora, para trabalhar em um, eu apenas faço
git checkout fix-game-save-bug
e comece a trabalhar. Confirme coisas, etc. Alternar entre ramificações, mesmo em um projeto tão grande quanto o chrome, é quase instantâneo. Na verdade, eu não sei como fazer isso em hg. Não faz parte de nenhum tutorial que li.
Outra grande diferença. Palco do Git.
Git tem essa ideia de um estágio. Você pode pensar nisso como uma pasta oculta. Quando você confirma, apenas confirma o que está no palco, não as mudanças na sua árvore de trabalho. Isso pode parecer estranho. Se você deseja confirmar todas as alterações em sua árvore de trabalho, você git commit -aadiciona todos os arquivos modificados ao estágio e os confirma.
Qual é o sentido do palco então? Você pode facilmente separar seus commits. Imagine que você editou joypad.cpp e gamesave.cpp e deseja confirmá-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 no mesmo arquivo você deseja copiar para o estágio, para que você possa dividir essas confirmações separadamente. Por que você gostaria de fazer isso? Como como commits separados, outros podem obter apenas os que desejam ou, se houver um problema, podem reverter apenas o commit que teve o problema.
git add --patch consulte linux.die.net/man/1/git-add or use git add -i, como em stackoverflow.com/questions/2372583/…
checkout -b <name>você pode simplesmente usar git branch <name>para criar um novo ramo sem mudar para ele
Há um gráfico de comparação dinâmica no blog versioncontrol, onde você pode comparar vários sistemas de controle de versão diferentes.
dir-a/foo.cpara dir-b/foo.ce continuar trabalhando para dir-b/foo.c, em seguida, o seu trabalho em dir-a/foo.cserão corretamente fundiu-se com o meu trabalho depois de um puxão.
Existem diferenças bastante significativas quando se trata de trabalhar com filiais (especialmente as de curto prazo).
É explicado neste artigo (BranchingExplained) que compara Mercurial com Git.
Existem colaboradores baseados no Windows no seu projeto?
Porque, se houver, a GUI do Git-for-Windows parece estranha, difícil e hostil.
Mercurial no Windows, por outro lado, é um acéfalo.
Em algum momento do ano passado, avaliei o git e o hg para meu próprio uso e decidi usar o hg. Eu senti que parecia uma solução mais limpa e funcionou melhor em mais plataformas na época. No entanto, foi principalmente uma reviravolta.
Mais recentemente, comecei a usar o git por causa do git-svn e da capacidade de atuar como um cliente do Subversion. Isso me conquistou e agora mudei completamente para o git. Eu acho que tem uma curva de aprendizado um pouco maior (especialmente se você precisar bisbilhotar por dentro), mas é realmente um ótimo sistema. Vou ler esses dois artigos de comparação que John postou agora.
Atualmente, estou migrando do SVN para um DVCS (enquanto escrevia sobre minhas descobertas, meu primeiro esforço real de blog ...) e fiz algumas pesquisas (= pesquisando no Google). Tanto quanto eu posso ver, você pode fazer a maioria das coisas com os dois pacotes. Parece que o git tem alguns recursos avançados mais ou melhores implementados, eu sinto que a integração com o Windows é um pouco melhor para o mercurial, com o TortoiseHg. Sei que também existe o Git Cheetah (tentei os dois), mas a solução mercurial parece mais robusta.
Vendo como eles são de código aberto (certo?), Acho que também não terão recursos importantes. Se algo é importante, as pessoas pedem, as pessoas codificam.
Eu acho que para práticas comuns, Git e Mercurial são mais que suficientes. Ambos têm grandes projetos que os utilizam (Git -> linux kernel, Mercurial -> projetos de fundação Mozilla, ambos entre outros, é claro), então eu não acho que eles realmente estejam faltando alguma coisa.
Dito isto, estou interessado no que as outras pessoas dizem sobre isso, pois isso seria uma excelente fonte para meus esforços de blogs ;-)
Há ótimas e exaustivas tabelas e gráficos de comparação no git, Mercurial e Bazaar no guia da InfoQ sobre DVCS .
Sei que isso não faz parte da resposta, mas, nessa nota, também acho que a disponibilidade de plug-ins estáveis para plataformas como NetBeans e Eclipse desempenham um papel em que a ferramenta é mais adequada para a tarefa, ou melhor, qual ferramenta é o melhor ajuste para "você". Ou seja, a menos que você realmente queira fazê-lo da maneira CLI.
O Eclipse (e tudo o que é baseado nele) e o NetBeans às vezes têm problemas com sistemas de arquivos remotos (como SSH) e atualizações externas de arquivos; esse é outro motivo pelo qual você deseja que tudo o que você escolhe funcione "perfeitamente".
Também estou tentando responder a essa pergunta para mim mesmo ... e resumi os candidatos ao Git ou Mercurial .. obrigado a todos por fornecerem informações úteis sobre esse tópico sem se tornarem religiosos.
Ainda outra comparação interessante de mercurial e git: Mercurial vs Git . O foco principal é interno e sua influência no processo de ramificação.
Se você estiver interessado em uma comparação de desempenho do Mercurial e do Git, consulte 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 mantém o crescimento do repositório sob controle ao mesmo tempo. O Git também é rápido, mas seu repositório cresce muito rapidamente com arquivos modificados até você reembalar - e esses podem ser muito lentos. Mas o repositório empacotado é muito menor que o Mercurial.
O site mercurial tem uma ó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, realmente ajudou a entender a mentalidade do Mercurial.
Se você estiver migrando do SVN, use o Mercurial, pois sua sintaxe é MUITO mais compreensível para os usuários do SVN. Fora isso, você também não pode dar errado. Mas verifique o tutorial do GIT e o HGinit antes de selecionar um deles.
Este link pode ajudá-lo a entender a diferença http://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 em campo. Eles provavelmente pensariam que vários doutores sobre o assunto seriam interessantes. Entre esses provavelmente estão os que projetaram o Git.
Mercurial é projetado com uma mentalidade diferente. Os desenvolvedores não devem se importar muito com o VCS e, em vez disso, devem dedicar seu tempo à sua principal função: engenharia de software. O Mercurial permite que os usuários usem e abusem alegremente do sistema sem deixá-los cometer erros não recuperáveis.
Qualquer ferramenta profissional deve vir com uma CLI claramente projetada e intuitiva. 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 deve 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ê recebe uma mensagem de que o sistema desfaz sua última transação.
No Git, você precisa digitar:
$ git reset --soft HEAD^
Então, ok, suponha que você tenha uma idéia do que é a redefinição. Além disso, você precisa saber o que são redefinições "--soft" e "--hard" (suposições intuitivas?). Ah, e claro, não esqueça o personagem '^' 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 mesclar seus galhos sem muito barulho. O Mercurial também inclui um servidor http simples que você ativa digitando
hg serve
E deixe que outras pessoas naveguem no seu repositório.
A conclusão é que o Git faz o que o Mercurial faz, de uma maneira muito mais complicada e com uma CLI muito inferior. Use o Git se você deseja transformar os VCS do seu projeto em um campo de pesquisa científica. Use o Mercurial se você deseja concluir o trabalho do VCS sem se preocupar muito com isso e concentre-se em suas tarefas reais.