Qual a melhor ferramenta de controle de versão: Subversion, Git ou Mercurial?

Subversion

Para usar o Subversion, você precisa entender os conceitos básicos de controle de versão: arquivo, diretório de trabalho, revisão, changeset, ramos e etiquetas (tags). Também é necessário conhecer as particularidades de implementação do Subversion em relação à ramificação através de diretórios, e à convenção da estrutura de diretórios trunk/branches/tags.

O modelo de comandos de transporte é apresentado a seguir:

Há apenas dois lugares onde o fontes podem estar: no diretório de trabalho ou no repositório. Os comandos mais usados são poucos, coerentes e fáceis de lembrar.

O Subversion é simples e direto. Seu tempo de aprendizado é curto, e a chance de desastres causados por imperícia é pequeno.

Mercurial

O Mercurial é um pouco mais complicado que o Subversion porque além dos conceitos de controle de versão centralizado, também é necessário entender conceitos básicos do controle de versão distribuído, tais como sincronização de repositórios e o registro do histórico em um grafo acíclico direcionado.

O Mercurial não possui nenhuma particularidade de implementação que fique exposta na estrutura do projeto ou nos comandos. Mesmo operações avançadas como rebase, por exemplo, exigem apenas conceitos básicos de controle de versão distribuído.

O modelo de comandos de transporte é apenas um pouco mais complexo que o do Subversion:

Os comandos do Mercurial são iguais ou muito parecidos com o do Subversion. O novo nível do repositório remoto traz também novas operações adicionais como pull, push e rebase. Mesmo assim, os comandos mais usados ainda são poucos, coerentes e fáceis de lembrar.

A simplicidade de operação do Mercurial não impede que seja capaz de fazer operações complexas e ter funcionalidades adicionais 2:

Mercurial é projetado para oferecer um conjunto de comandos pequeno, seguro e fácil de usar que é suficientemente poderoso para a maioria dos usuários. Operações avançadas estão disponíveis através de extensões, que permitem a integração desses recursos diretamente no núcleo Mercurial.

Assim, o conjunto de operações e funcionalidades do Mercurial pode ser incrementado à medida que aumenta o nível de conhecimento e necessidade do usuário.

O Mercurial ainda possui medidas internas de segurança que evitam estragos por imperícia mesmo em operações avançadas de manipulação de histórico. O conceito de Phases (fases), por exemplo, é transparente ao usuário e evita que histórico já compartilhado seja reescrito por acidente.

O Mercurial é um pouco mais complexo que o Subversion, mas também é bastante simples de aprender e usar. Possui medidas de segurança que evitam desastres por imperícia.

Git

Git tem várias qualidades: é popular principalmente entre projetos open source, é rápido (até um certo tamanho de projeto) e tem um bom design interno. Porém, simplicidade não está entre essas qualidades. Pelo contrário, o Git é bastante complexo e sua interface é inconsistente e pouco intuitiva.

A complexidade do Git aparece de várias formas, uma delas é no seu modelo de comandos transporte 3:

Há vários lugares onde os arquivos podem estar: stash, diretório de trabalho (working tree na terminologia do Git), index (também chamado de stage area ou cache), repositório local e remoto. A área stash é opcional, mas o index não pode ser evitado completamente. Trata-se de uma área intermediária de preparação para a geração da revisão.

O index é um elemento da infraestrutura. Toda ferramenta de controle de versão tem um elemento equivalente, mas enquanto o Subversion, Mercurial, Bazaar, Darcs etc. coordenam isso automaticamente 4, no Git, o index precisa ser gerenciado diretamente pelo usuário. Principalmente para usuários iniciantes e intermediários, os poucos casos em que o gerenciamento direto do index é útil não compensam todo o esforço e complexidade adicionais, nem os riscos de se consolidar uma configuração diferente da que foi analisada e testada no diretório de trabalho.

A exposição do index é um exemplo na falha da abstração do Git, mas não é o único. O microgerenciamento de outros elementos da infraestrutura para execução de operações de controle de versão é bastante comum no Git. Ao invés de executar uma operação de alto nível de abstração, o usuário precisa manipular conceitos e estruturas de implementação como bare repos, blob, fast-forward, detached HEAD, refs, reflog, refspecs, remote, hard reset, tree, working tree e upstream.

Se o Git fosse um carro, para aprender a dirigi-lo você precisaria antes entender como funciona o motor de combustão interna. Para acelerar, não bastaria apenas pisar no pedal do acelerador; no carro Git seria necessário entender o funcionamento da sonda lambda e acionar diretamente a válvula-borboleta para liberar mais ar para a mistura ar-combustível e, assim, dar mais potência ao motor.

Grande parte dessa complexidade se deve às origens do Git 5:

O Git é fundamentalmente um sistema de arquivos de conteúdo endereçável com uma interface de usuário para controle de versão de software escrita em cima.

Inicialmente, o Git era um conjunto de ferramentas para um controle de versão ao invés de um controle de versão completo, tem um monte de verbos que fazem trabalho de baixo nível que foram projetados para serem encadeados no estilo UNIX ou chamados de scripts. Esses comandos são geralmente referidos como comandos de "encanamento" (plumbing), e os comandos mais fáceis de usar são chamados comandos de "porcelana" (porcelain).

A versão 2.13 do Git (de maio de 2017) possui 148 comandos. Desses, 21 são considerados "porcelana" (listados pelo comando git help): add, bisect, branch, checkout, clone, commit, diff, fetch, grep, init, log, merge, mv, pull, push, rebase, reset, rm, show, status e tag.

Mesmos esses comandos sofrem de baixa usabilidade. Vários deles não funcionam como se espera se comparados com os conceitos clássicos de controle de versão. O comando git clone, por exemplo, não cria realmente um clone de um repositório. O comando para isso seria git clone --mirror. Ainda assim, o repositório criado não é usável diretamente porque não possui um diretório de trabalho associado.

Outro exemplo é comando git pull, que deveria somente trazer as revisões do repositório remoto para o repositório local, mas faz também a mesclagem automática. A operação do Git que faz o pull clássico é git fetch.

A interface do Git também apresenta muitos problemas de inconsistência. Exemplos 6:

A tirinha do xkcd ilustra bem a situação da usabilidade do Git:

- Este é o Git. Ele registra o trabalho colaborativo em projetos
através de um belo modelo distribuído de árvore de teoria de grafos.
- Legal. E como se usa?
- Não faço ideia. Apenas decore esses comandos e digite-os para sincronizar.
Se aparecer erros, salve seu trabalho em outro lugar,
apague o projeto e faça o download de uma nova cópia.

Toda essa complexidade e excessiva exposição de detalhes torna o Git difícil de aprender e usar 7:

Uma das diferenças mais proeminentes entre o Git vs Mercurial é o nível de conhecimento necessário para usar os sistemas. Em resumo, o Git é mais complexo e exige que você e sua equipe o conheçam dentro e fora antes que você possa esperar usá-lo de forma eficaz e segura. Com o Git, um desenvolvedor descuidado pode causar grandes danos para toda a equipe. Além disso, sua documentação é considerada mais difícil de entender.

Outra consequência da complexidade do Git é a facilidade com que erros de operação acontecem. Um comando errado executado por um desenvolvedor descuidado ou despreparado pode facilmente levar a situações muito difíceis de sair. Casos bastante comuns incluem o git rebase de um ramo compartilhado e o mal uso de operações como git push --force e git push --mirror. Embora a perda de código seja rara, é necessário bastante conhecimento técnico para desfazer a bagunça, principalmente depois se o estrago tiver sido compartilhado com outros desenvolvedores.

É importante ressaltar que o excesso de complexidade e exposição de detalhes não trazem nenhuma melhoria na produtividade nem tampouco torna o controle de versão mais efetivo. As mesmas operações de controle de versão são muito mais facilmente executadas pelo Mercurial ou pelo Subversion, sem a necessidade de recorrer frequentemente ao Google ou StackOverflow para descobrir qual o comando e a sintaxe corretas para uma operação como ocorre no Git.

O Git é bastante difícil de aprender e usar. Desastres por imperícia são comuns, principalmente com desenvolvedores despreparados.