O quê são sistemas de controle de versão centralizados e distribuídos e quais são as suas diferenças
Atualizado
Isto foi útil?
O Git, sistema de controle de versão que vamos estudar neste livro, é um sistema distribuído. Mas, antes de irmos direto para esse modelo mais moderno, é importante entender como os sistemas centralizados funcionavam — e por que eles motivaram a criação de algo novo.
Mesmo que você não vá usar um sistema centralizado na prática, entender como ele funciona ajuda a compreender melhor o Git. Muitas decisões do Git fazem mais sentido quando conhecemos os problemas que ele veio resolver.
Em algum momento, você provavelmente vai se perguntar: “Mas por que o Git faz isso desse jeito tão complicado?”. Com esse contexto, o que parece esquisito no começo passa a fazer sentido — e você percebe que existe uma lógica por trás de tudo.
No mais, não se preocupe em entender especificidades dos sistemas centralizados. O foco deste livro é o modelo distribuído — e é nele que vamos mergulhar de verdade ao longo dos próximos capítulos.
Imagine que você e outras pessoas estão colaborando em um projeto. Para manter tudo organizado, vocês combinam de guardar os arquivos em um lugar compartilhado. Criam, então, uma pasta especial que reúne todos os arquivos do projeto e registra o histórico completo de alterações: o que foi mudado, por quem, quando e por quê. É como ter uma linha do tempo detalhada de tudo que já aconteceu no projeto.
Mas como várias pessoas poderiam colaborar ao mesmo tempo? Essa pasta poderia ficar em outro computador — um servidor — que funcionaria como o ponto central do projeto. Assim, todo mundo poderia acessar e contribuir, sem precisar estar no mesmo lugar ou usar o mesmo computador.
IMAGEM
Cada pessoa que quisesse colaborar com o projeto poderia baixar para o seu computador a versão mais recente de cada arquivo.
IMAGEM
Depois, faria as alterações necessárias localmente e, em seguida, enviaria de volta apenas o que tivesse mudado — os arquivos modificados, adicionados ou removidos. Os arquivos que permanecessem iguais não precisariam ser reenviados.
Parece que funcionaria bem! Mas... e se mais de uma pessoa quiser editar o mesmo arquivo ao mesmo tempo? Aí a coisa complica, né?
Para lidar com isso, vocês poderiam adotar uma estratégia de bloqueio. Quando alguém começa a editar um arquivo, avisa que ele está bloqueado, impedindo que outras pessoas façam alterações até que o bloqueio seja liberado. Esta estratégia era utilizada em um controle de versão chamado Microsoft Visual SourceSafe, que, aliás, tinha muitos problemas exatamente por este mecanismo.
Outra possibilidade seria permitir que todo mundo edite livremente. Depois, quando as alterações fossem reunidas novamente na pasta compartilhada, alguém precisaria comparar o que mudou e tentar mesclar os conteúdos. Se duas pessoas tivessem mexido na mesma parte de um arquivo, isso poderia gerar conflitos — e aí alguém teria que resolvê-los manualmente.
Esse é exatamente o funcionamento de um sistema de controle de versão centralizado. Agora que a ideia geral está clara, vamos ver como isso tudo é chamado na prática — os nomes e termos usados pra descrever essas partes e ações no jeito como o sistema foi pensado.
Agora que já vimos como funciona, de forma geral, um sistema de controle de versão centralizado, vamos conhecer alguns dos termos mais usados nesse modelo.
Logo depois dessa explicação, vamos ver um exemplo prático de uso, que vai ajudar a entender melhor como tudo isso acontece na prática.
É uma pasta onde ficam guardados todos os arquivos do projeto e o histórico completo das versões. E é chamado de remoto porque geralmente essa pasta não está no seu computador, mas sim em outro — um servidor — acessado pela internet. E é chamado de central porque é o ponto principal de encontro: todas as pessoas colaboradoras acessam essa mesma pasta para enviar e receber alterações.
É o processo de obter uma cópia de trabalho do projeto a partir do repositório central. Essa cópia traz apenas os arquivos mais atuais — ou seja, a versão mais recente de cada um. O histórico completo não fica salvo localmente: ele continua no servidor. Por isso, qualquer consulta ao passado ou envio de mudanças depende de uma conexão com o repositório central.
É o processo de atualizar a cópia local do projeto com as alterações mais recentes que foram enviadas ao repositório central. É uma forma de manter o ambiente de trabalho sincronizado com o que outras pessoas já modificaram.
É o processo de enviar as mudanças feitas localmente — arquivos adicionados, modificados ou removidos — de volta para o repositório central. Isso permite que outras pessoas também tenham acesso a essas alterações.
É uma estratégia usada para evitar conflitos: ao editar um arquivo, a pessoa sinaliza que ele está “travado” para alterações por outras pessoas. O sistema, então, garante que apenas uma pessoa faça mudanças naquele arquivo por vez, reduzindo o risco de sobrescrever o trabalho de alguém.
É o processo de combinar ("mesclar") alterações feitas por pessoas diferentes que editaram o mesmo arquivo. Se cada uma modificou partes diferentes do conteúdo, as mudanças costumam ser integradas automaticamente. Mas, se duas pessoas alteraram a mesma parte do arquivo, ocorre um conflito — e alguém precisa revisar essas alterações para decidir qual versão deve ser mantida.
Uma pessoa A e uma pessoa B decidem criar um blog. A pessoa A cria uma estrutura inicial do blog em seu computador e envia ("PUSH") essa versão para o repositório central.
A pessoa B se anima com o projeto e também quer contribuir, criando o seu primeiro blog post. Para isso, B precisa ter acesso à versão criada por A, que já está no repositório central no momento. B precisa fazer um "PULL", que nada mais é que fazer uma cópia da última versão do projeto que está no repositório central para a sua máquina local.
Agora, B tem acesso, em seu computador, ao projeto em sua versão mais atual. B escreve seu primeiro blog post e precisa enviar as mudanças de volta para o repositório central, para que A também possa ver o seu belo trabalho. B faz um "PUSH" do seu código, ou seja, envia uma cópia da sua versão para o repositório central.
Tudo pronto! Temos no repositório central a versão mais recente do blog, a qual contém o post de B. A versão inicial de A também está lá, guardada caso alguém precise consultá-la para comparar diferenças, ou até mesmo para reverter alguma alteração.
Mas, e se A também estiver empolgado e não conseguir esperar por B? Ao mesmo tempo que B, A começa a escrever seu próprio post. Quando A tenta enviar seu código para o repositório central, percebe que B já enviou antes a sua versão.
E para piorar, A e B modificaram o mesmo arquivo! E agora?
Bom, é aí que entra em jogo umas das principais funcionalidades de um sistema de controle de versão: o auxílio no Gerenciamento de Conflitos. O sistema lida com as mudanças feitas por diferentes colaboradores no mesmo arquivo, evitando conflitos e garantindo uma integração suave das alterações. Isso é feito por meio de um processo chamado 'mesclagem', que combina o trabalho de todos de forma harmoniosa e mantém a consistência do projeto.
Dessa forma, A consegue tranquilamente enviar suas modificações sem comprometer em nada as mudanças feitas por B.
Exemplos de sistemas centralizados de controle de versão incluem o Subversion (SVN) e o Microsoft Team Foundation Version Control (TFVC). Embora os sistemas centralizados tenham sido amplamente utilizados no passado, muitas equipes estão migrando para sistemas de controle de versão distribuídos, como o Git, devido à sua flexibilidade, desempenho e recursos avançados que iremos começar a desvendar aos poucos daqui para frente.
