Início > Artigos & Tutoriais > Conceitos Básicos de Controle de Versão

Conceitos Básicos de Controle de Versão de Software — Centralizado e Distribuído   (pg. 3 de 6)

Autor: André Felipe Dias. Última atualização em 19/06/2009

3. Como Funciona o Controle de Versão?

O controle de versão é composto de duas partes: o repositório e a área de trabalho. O repositório armazena todo o histórico de evolução do projeto, registrando toda e qualquer alteração feita em cada item versionado.

O desenvolvedor não trabalha diretamente nos arquivos do repositório. Ao invés disso, usa uma área/cópia de trabalho que contém a cópia dos arquivos do projeto e que é monitorada para identificar as mudanças realizadas. Essa área é individual e isolada das demais áreas de trabalho.

Estrutura de um controle de versão é composta por repositório e área de trabalho. A comunicação entre elas se dá através de operações de commit e update.

A sincronização entre a área de trabalho e o repositório é feita através dos comandos de commit e update.

O commit envia um pacote contendo uma ou mais modificações feitas na área de trabalho (origem) ao repositório (destino). O update faz o inverso, isto é, envia as modificações contidas no repositório (origem) para a área de trabalho (destino).

Cada commit gera uma nova revisão no repositório, contendo as modificações feitas, data e autor. Uma revisão funciona como uma "foto" de todos os arquivos e diretórios em um determinado momento da evolução do projeto. As "fotos" antigas são mantidas e podem ser recuperadas e analisadas sempre que desejado. O conjunto dessas revisões é justamente o histórico do projeto.

Tanto o controle de versão centralizado quanto o distribuído possuem repositórios e áreas de trabalho. A diferença está em como cada uma dessas partes está arranjada.

Controle de Versão Centralizado

O controle de versão centralizado segue a topologia em estrela, havendo apenas um único repositório central mas várias cópias de trabalho, uma para cada desenvolvedor. A comunicação entre uma área de trabalho e outra passa obrigatoriamente pelo repositório central.

No controle de versão centralizado há um único repositório e várias cópias de trabalho que se comunicam apenas através do repositório central.

Controle de Versão Distribuído

São vários repositórios autônomos e independentes, um para cada desenvolvedor. Cada repositório possui uma área de trabalho acoplada e as operações commit e update acontecem localmente entre os dois.

No controle de versão distribuído cada desenvolvedor possui um repositório próprio acoplado a uma área de trabalho. A comunicação entre eles continua sendo através de commit e update.

Um repositório pode se comunicar com qualquer outro através de duas operações básicas: pull e push:

• Pull (Puxar). Atualiza o repositório local (destino) com todas as alterações feitas em outro repositório (origem).
• Push (Empurrar). Envia as alterações do repositório local (origem) para um outro repositório (destino).

Um repositório recebe e envia revisões com qualquer outro através de operações pull e push sem a necessidade de uma topologia pré-definida.

A sincronização entre os desenvolvedores acontece de repositório a repositório e não existe, em princípio, um repositório mais importante que o outro, embora o papel de um repositório central possa ser usado para convencionar o fluxo de trabalho.

Resumo das Operações Básicas dos Controles de Versão Centralizado e Distribuído

Centralizado	Distribuído	Descrição
checkout	clone	criação da cópia de trabalho/repositório
commit	commit	envia alterações para o repositório, criando uma revisão
update	update	atualiza a cópia/área de trabalho em uma revisão
	pull	importa revisões feitas em outro repositório
	push	envia revisões locais para outro repositório

Identificação de Revisões

Uma revisão precisa de uma identificação única. No controle de versão centralizado, cada revisão produzida recebe um número inteiro sequencial: 1, 2, 3... Como só existe um repositório, a númeração de revisão é a mesma para todos os desenvolvedores.

Exemplo numeração sequencial de revisões de um projeto baseado em controle de versão centralizado.

No sistema distribuído, os repositórios são autônomos e portanto não há como definir uma numeração sequencial compartilhada para todos. A solução é identificar cada revisão com uma numeração que nunca se repita em qualquer outro repositório.

A forma mais usada é através de um hash SHA-1, que produz um número de 160 bits (40 dígitos na forma hexadecimal). Esse um número é tão grande e específico que torna extremamente improvável a colisão com um hash produzido por outro repositório.

Exemplo de revisões identificadas por hash de um projeto baseado em controle de versão distribuído. Na figura, apenas os primeiros dígitos do hash são mostrados.

« Anterior |  Próxima » |  1  2  3  4  5  6  | Página única