Um fato é que se considerarmos as funcionalidades e desempenho equivalentes (ou muito aproximados), a afinidade do Git ou Mercurial com as características da empresa/projeto/equipe se mostrarão mais importantes e desempatar será cada vez mais decidida por aspectos subjetivao como proximidade com outros projetos relacionados e preferência dos desenvolvedores.
Projetos Relacionados
Projetos maiores que já usam o Mercurial ou o Git acabam atraindo projetos relacionados para o seu campo de influência.
A interferência direta se dá quando é necessário acompanhar ou mesmo participar de certos projetos externos associados com o projeto da equipe. A escolha da mesma ferramenta para todos torna o controle de versão muito mais fácil pois define um padrão homogêneo.
A tabela a seguir apresenta alguns projetos e qual a ferramenta que usam.
Projeto | Git | Mercurial |
---|---|---|
Google Android | X | |
Google Code | X | |
Pylons | X | |
Python (linguagem) | X | |
Ruby on Rails | X | |
Sun (OpenJDK, NetBeans, OpenSolaris) | X |
Preferência dos Desenvolvedores
Esse é o critério mais passional de todos. O que leva um desenvolvedor a preferir uma ferramenta a outra varia desde a identificação com a filosofia do projeto até a preferência pelo logotipo do projeto. De qualquer modo, uma tendência clara da equipe por uma ferramenta específica deve ser pesado na decisão final.
Estudos de Caso
Projeto X | Projeto Y | Projeto Z | |
---|---|---|---|
Escolha Final | Mercurial | Git | Mercurial |
Plataforma | Windows | Windows/Linux | Linux |
IDE/Interface | Eclipse | NetBeans | linha de comando |
Linguagem Principal | Java | Ruby | Python |
Projetos relacionados usam | Subversion/Mercurial | Git | Subversion/Mercurial |
Preferência dos Desenvolvedores | - | Git | Mercurial |
Considerações Finais
Git e Mercurial são ambas ótimas opções de controle de versão distribuído. A análise de um ou outro baseado em número de funcionalidades, forma de implementação interna, desempenho etc. acaba caindo em um tipo de discussão que abunda pelas listas de discussão na internet a fora e que gera muito calor e pouca luz!
Em termos práticos, ambas as ferramentas são muito parecidas e é mais fácil (e prático) escolher entre uma e outra com base na afinidade com o projeto/equipe.
É bom lembrar que controle de versão é muito mais que instalar a ferramenta e sair usando. É necessária a capacitação dos desenvolvedores, a definição de um processo de GCS em sintonia com as particularidades da ferramenta e também integração com uma ferramenta de controle de mudança (por exemplo, o Trac).
Nenhum comentário:
Postar um comentário