Tipos de Controle de Versão | CloudMotion
Sistema de Controle de Versão Centralizado
Sistema de controle de versão centralizado é um modelo baseado em cliente-servidor, ou seja, as máquinas da equipe do projeto precisam estar conectadas a um servidor central que contém o sistema de controle de versão com os arquivos versionados do projeto.
Exemplo de um sistema de controle de versão centralizado (clique para ampliar)
Nesse modelo, na máquina do desenvolvedor contém apenas um cópia local dos arquivos e todo o resto fica no servidor central. Nesse servidor central é onde vão ficar armazenadas todas as versões do projeto.
Quando o membro do time do projeto termina de executar sua alteração, ele deve fazer um commit/ check-in para que sua alteração seja guardada no servidor. Nesse processo o cliente conecta no servidor, manda os arquivos alterados e o servidor realiza o trabalho de executar o snapshot desses arquivos do código-fonte do sistema.
Um ponto falho nesse processo é que se o servidor central ficar fora do ar, não será possível trabalhar com o seu time e nem gerar novas versões do seu código-fonte.
Exemplos de possíveis problemas no modelo centralizado: terminei de fazer minha alteração e quero versionar para iniciar outra atividade, por o servidor estar fora, não poderemos subir essa versão e complica o início do trabalho da próxima funcionalidade. Outro problema seria, você está trabalhando na resolução de um defeito no seu sistema e quer ver um histórico para entender algumas alterações relizadas, quem foi que fez, para que você possa conversar com essa pessoa. Como o histórico fica todo no servidor central, precisaríamos de conexão com ele para realizar essa operação.
Uma vantagem é que os administradores do sistema de controle de versão podem ter um controle maior sobre quem pode fazer o que.
Sistema de Controle de Versão descentralizado
Ao contrário do modelo centralizado, o descentralizado não depende exclusivamente de um servidor central para guardar todas as versões do seu código-fonte. Isso significa que quando um membro do time faz o clone do projeto, é realizado o download da base de dados completa para máquina dele.
Realizando o download da base de dados completa, o desenvolvedor passa a ter em sua própria estação de trabalho todas as versões do código-fonte, permitindo gerar novas versões e até mesmo olhar e voltar para versões antigas do arquivo que desejar.
Exemplo de um sistema de controle de versão descentralizado (clique para ampliar)
Algumas vantagens desse modelo centralizado são:
Permite que os membros da equipe continuem sendo produtivos mesmo que não estejam conectados no servidor;
Operações comuns (por exemplo, commit, ver o histórico, reverter versões) são mais rápidas nesse modelo pois não precisam se comuinicar com os servidores;
Permitem que os membros de equipe possam trabalhar em versões de teste que eles não desejam que outros vejam.
Algumas desvantagens do modelo são:
O processo inicial de trazer os arquivos para a máquina do desenvolvedor é mais lento em comparação com o modelo centralizado, pois durante o processo de clonagem, todo o histórico, branches são copiadas para sua estação de trabalho.
Falta de um controle mais granular nas ações que um usuário pode fazer dentro do sistema de controlador de versão.
02/04/2019 | Por Claudio Romão | Em Técnico | Tempo de leitura: 3 mins.
Bom a ideia dos posts é seguir uma lógica que nós utilizaríamos em algum projeto. Eu poderia começar tanto pelo... (Continua)