Você deve usar uma alternativa ao Git?

O Git é incrivelmente popular e suporta quase todos os lugares. Sendo praticamente o sistema de controle de versão padrão, ele levanta a questão: quais são suas alternativas? Vale a pena considerar e como são diferentes?

Observe que este artigo discute alternativas ao git como software de controle de origem. Se você está simplesmente procurando alternativas para um serviço hospedado como o Github, pode ler o nosso guia para soluções Git hospedadas.

As desvantagens do Git

Para entender melhor as limitações do Git, devemos primeiro começar com o que ele faz certo.

O Git usa um modelo de controle de fonte distribuído; o repositório local de cada usuário não está realmente conectado a qualquer servidor central. Esse usuário pode ficar offline, fazer várias alterações e ninguém mais as verá até serem enviadas para o controle remoto. Isso funciona muito bem para o desenvolvimento de software de código aberto; O Git é muito mais rápido para a maioria das ações, pois todos os usuários podem clonar um repositório e fazer suas próprias pequenas alterações sem ter que se preocupar com o que as outras pessoas estão fazendo.

Essas alterações podem ser integradas ao repositório principal usando solicitações pull (o usuário que faz as solicitações de alteração para o repositório mestre receber confirmações de sua versão privada do repositório) e atualizações enviadas por usuários autenticados, desde que todos os conflitos de mesclagem sejam resolvidos. resolvido adequadamente.

Este modelo faz muito sentido para esse ambiente de desenvolvimento distribuído, mas o problema com o Git surge quando você tenta adaptá-lo para uso em um ambiente corporativo, onde você normalmente terá muitas pessoas trabalhando nos mesmos bits do código, e a coordenação adequada é a chave.

Não nos entenda mal aqui, ainda é fantástico, especialmente quando combinado com software de rastreamento de problemas externos e pipelines de CI / CD, algo que serviços como GitLab e BitBucket fazem muito bem. Mas o Git não foi exatamente construído para ser um controle de origem corporativo, onde você quase sempre terá um servidor central atuando como repositório principal. Requer um uso muito adequado (e muitas vezes ferramentas externas) para ser eficaz para equipes ágeis que realizam muitas alterações de código.

Com o Git, cada cliente armazena uma cópia completa do changelog do projeto. Toda vez que você faz uma confirmação no Git, ele armazena as alterações que foram feitas localmente no seu sistema. Isso torna o trabalho com o Git muito rápido, pois você só precisa consultar um disco rígido e não um servidor central. Também permite que você trabalhe offline com muito mais facilidade. Porém, com grandes projetos com um longo histórico de alterações, isso também pode levar a pasta . git a ocupar uma quantidade razoável de espaço.

Além disso, se você possui vários projetos, provavelmente não deseja o código-fonte para tudo o que é visível para cada desenvolvedor. No Git, esse problema geralmente é resolvido com repositórios separados para cada projeto, o que funciona muito bem, mas não é o ideal se você precisar integrá-los em uma única peça coesa. Com o controle de versão centralizado, você pode acessar apenas pastas específicas.

Portanto, embora o Git provavelmente não seja a escolha errada para os seus negócios, especialmente se implementado adequadamente, existem outras opções de controle de origem criadas especificamente para fluxos de trabalho corporativos, e pode valer a pena olhar para a concorrência.

RELACIONADO: Como configurar um servidor pessoal do Gitlab

A alternativa primária: controle centralizado de versões

A diferença mais comum entre o Git e as alternativas é a quebra do controle de versão descentralizado em favor de um servidor central e autoritário. O Apache Subversion e o Team Foundation Version Control são os principais sistemas de controle de versão que seguem esse formato.

Para comparação, em um sistema DVC, cada usuário possui um repositório local no qual eles efetuam suas próprias alterações. Quando eles estão prontos para enviar atualizações para o servidor mestre, é possível que outros usuários tenham versões diferentes do mesmo arquivo em que você está trabalhando. Isso é conhecido como conflito de mesclagem e é um problema muito comum (embora facilmente resolvível) com o Git.

No controle de versão centralizado (CVC), como o Apache Subversion, existe um repositório de servidor único e muitos clientes conectados diretamente a ele. Se você alterar um arquivo, esse arquivo será atualizado nas máquinas de outros usuários sempre que elas forem atualizadas. As confirmações são feitas diretamente no servidor principal.

Para evitar conflitos de mesclagem, a maioria dos sistemas CVC usa bloqueios. Se o Usuário A desejar trabalhar em um arquivo e não quiser que ninguém mexa com ele, ele poderá bloquear o arquivo até que seja feito, impedindo que outros usuários façam o mesmo. Isso não é necessário no Subversion, e os conflitos de mesclagem ainda podem acontecer, mas são menos acidentes.

O problema é atenuado principalmente por cópias locais e de ramificação, que permitem que vários usuários trabalhem em suas próprias versões por longos períodos de tempo antes de mesclar as alterações.

Outro ótimo recurso do controle de versão centralizado é o gerenciamento de permissões; ao invés de dar acesso a todo o repositório, o CVC facilita a seção de acesso a pastas específicas. O Team Foundation Version Control funciona da mesma maneira que o Subversion, permitindo a delegação granular de permissões até o nível do arquivo.

Todos esses recursos tornam o controle de versão centralizado uma alternativa viável ao DVC. Afinal, o Google hospeda todo o seu código em um sistema massivo e centralizado, muito maior do que qualquer sistema distribuído poderia suportar. É verdade que a base de código do Windows é um repositório Git de 300 GB, mas que está usando o plug-in Virtual File System do Git, que permite que os usuários baixem apenas os arquivos de que precisam e nada mais.

No entanto, uma desvantagem do Subversion é que muitas cópias e downloads são necessários, o que pode torná-lo muito mais lento que o modelo local do Git.

RELACIONADO: As melhores alternativas ao Github

Outras alternativas

Enquanto nos concentramos em sistemas de controle de versão centralizados que podem substituir o Git, existem outros sistemas de controle de versão distribuídos que você pode usar, principalmente o Mercurial.

O Mercurial é um pouco mais fácil de usar do que o Git, e eles são quase o mesmo em termos de desempenho, mas no geral eles são muito semelhantes. Realmente, não há muito motivo para escolher Mercurial em vez de Git, exceto a preferência pessoal, que provavelmente não deveria estar ditando decisões corporativas.

O Mercurial costumava ser uma opção no BitBucket, mas eles abandonaram o suporte recentemente, a principal razão é que o Git é muito mais popular e amplamente suportado. É praticamente o sistema de controle de versão padrão e, a menos que uma alternativa esteja mudando radicalmente o modelo (como o CVC), não vale a pena considerar.

Via: How to Geek