Sistema de controle de versão

Um sistema de controle de versão (ou versionamento), VCS (do inglês

version control system) ou ainda SCM (do inglês source code management)
na função prática da Ciência da Computação e da Engenharia de Software, é
um software com a finalidade de gerenciar diferentes versões no
desenvolvimento de um documento qualquer. Esses sistemas são
comumente utilizados no desenvolvimento de software para controlar as
diferentes versões — histórico e desenvolvimento — dos códigos-fontes e
também da documentação.

Esse tipo de sistema é muito presente em empresas e instituições de

tecnologia e desenvolvimento de software. É também muito comum no
desenvolvimento de software livre. É útil, em diversos aspectos, tanto para
projetos pessoais pequenos e simples como também para grandes projetos
comerciais.

Entre os mais comuns encontram-se as soluções livres: CVS, Mercurial, Git e

SVN; e as comerciais: SourceSafe e ClearCase. O desenvolvimento de
software livre prefere o SVN que vem substituindo o clássico CVS. Muitas
empresas também adotam o SVN, embora algumas empresas prefiram uma
solução comercial, optando pelo ClearCase (da IBM) ou SourceSafe (da
Microsoft). Optar por uma solução comercial geralmente está relacionada à
garantia, pois as soluções livres não se responsabilizam por erros no
software e perdas de informações[1], apesar das soluções livres poderem
ter melhor desempenho e segurança que as comerciais. As soluções
comerciais apesar de supostas garantias adicionais não garantem o sucesso
da implementação nem indenizam por qualquer tipo de erro mesmo que
comprovadamente advindo do software.

A eficácia do controle de versão de software é comprovada por fazer parte

das exigências para melhorias do processo de desenvolvimento de
certificações tais como CMMI e SPICE.[2]
Índice
[esconder]

1 Principais vantagens
2 Funcionamento básico
2.1 Envio e resgate de versões
2.2 Histórico de envio
2.3 Trabalho em equipe
2.3.1 Mesclagens Otimistas vs Edições Exclusivas
2.3.2 Demonstração de "Mesclagens Otimistas" passo-a-passo
2.3.2.1 1° passo: atualizando
2.3.2.2 2° passo: desenvolvendo
2.3.2.3 3° passo: submetendo
2.3.2.4 4° passo: necessita atualização
2.3.2.5 5° passo: baixando atualização e mesclando
2.3.2.6 6° e último passo: submetendo a versão final
2.3.3 "Edições Exclusivas" ou ausência de um sistema de controle
de versão
2.3.3.1 Mesclagem no método "Edições Exclusivas"
2.3.4 Bloqueio de arquivo
2.4 Comparação de versões
 2.5 Conflitos
2.5.1 Mesclagem
2.5.2 Resolução manual de conflitos
2.6 Ramificações e marcações
2.7 Otimização de espaço e velocidade
3 Integração com outros softwares
4 Vocabulário comum
5 Lista de sistemas de controle de versão
6 Notas e referências
7 Bibliogafia
8 Ver também
9 Ligações externas

Principais vantagens

As principais vantagens de se utilizar um sistema de controle de versão

para rastrear as alterações feitas durante o desenvolvimento de software ou
o desenvolvimento de um documento de texto qualquer são:

* Controle do histórico: facilidade em desfazer e possibilidade de analisar

o histórico do desenvolvimento, como também facilidade no resgate de
versões mais antigas e estáveis. A maioria das implementações permitem
analisar as alterações com detalhes, desde a primeira versão até a última.
* Trabalho em equipe: um sistema de controle de versão permite que
diversas pessoas trabalhem sobre o mesmo conjunto de documentos ao
mesmo tempo e minimiza o desgaste provocado por problemas com
conflitos de edições. É possível que a implementação também tenha um
controle sofisticado de acesso para cada usuário ou grupo de usuários.
* Marcação e resgate de versões estáveis: a maioria dos sistemas
permite marcar onde é que o documento estava com uma versão estável,
podendo ser facilmente resgatado no futuro.
* Ramificação de projeto: a maioria das implementações possibilita a
divisão do projeto em várias linhas de desenvolvimento, que podem ser
trabalhadas paralelamente, sem que uma interfira na outra.

Funcionamento básico

Cada implementação possui sua particularidade, mas a maioria deles

compartilham alguns conceitos básicos. Nota: Apesar disso, é possível que
algum sistema específico funcione de maneira totalmente diferente da
explicada neste capítulo.

A maior parte das informações - com todo o histórico - ficam guardadas num
repositório (repository em inglês), num servidor qualquer. Geralmente o
acesso é feito por um cliente pela rede (via socket) e pode ser feito
localmente quando o cliente está na mesma máquina do servidor.

O repositório armazena a informação - um conjunto de documentos - de

modo persistente num sistema de arquivos ou num banco de dados
qualquer. É possível que o armazenamento seja feito em outros dispositivos
capazes de "eternizar" e resgatar facilmente a informação.

Cada servidor pode ter vários sistemas de controle de versão e cada

sistema pode ter diversos repositórios, limitando-se na capacidade de
gerenciamento do software e também no limite físico do hardware.
Geralmente um repositório possui um endereço lógico que permite a
conexão do cliente. Esse endereço pode ser um conjunto IP/porta, uma URL,
um caminho do sistema de arquivos etc.

Cada desenvolvedor possui em sua máquina uma cópia local (também

chamada de working copy em inglês) somente da última versão de cada
documento. Essa cópia local geralmente é feita num sistema de arquivos
simples (FAT, NTFS, ext3 etc). A cada alteração relevante do desenvolvedor
é necessário "atualizar" as informações do servidor submetendo (commit
em inglês) as alterações. O servidor então guarda a nova alteração junto de
todo o histórico mais antigo. Se o desenvolvedor quer atualizar sua cópia
local é necessário atualizar as informações locais, e para isso é necessário
baixar novidades do servidor (ou fazer update em inglês).

fig. a - Esquema geral físico. "Sistema" representa o sistema de controle de

versão do lado Servidor (server-side). "Software Cliente" representa o
sistema de controle de versão do lado Cliente (client-side).

fig. a - Esquema geral físico. fig. b - Esquema

geral lógico.

Envio e resgate de versões

A principal função do sistema de controle de versão é armazenar todo o

histórico de desenvolvimento do documento, desde o primeiro envio até sua
última versão. Isso permite que seja possível resgatar uma determinada
versão de qualquer data mais antiga, evitando desperdício de tempo no
desenvolvimento para desfazer alterações quando se toma algum rumo
equivocado.

O envio das alterações é feito a gosto do desenvolvedor (do lado do cliente),

quando ele desejar; mas, para minimizar conflitos de versões, facilitar no
desfazer de alterações e também no controle do histórico, recomenda-se
que uma alteração seja enviada cada vez que o software estiver
minimamente estável, i. e., a cada nova parte (uma função, e. g.) ou a cada
alteração relevante que esteja funcionando corretamente. Não é
recomendável o envio quando o documento como um todo possa causar
alguma dificuldade no desenvolvimento de outro colaborador, como por
exemplo um código não compilando ou com algum defeito que comprometa
a execução geral.
Cada "envio" é na maioria dos sistemas chamado de "commit" (as vezes
"submit"), ou seja, efetivar as alterações no (ou "submeter" ao) repositório.
Cada envio produz uma nova versão no repositório e é armazenado como
"uma fotografia" do momento.

fig. c - Em sistemas no estilo do CVS, cada documento tem sua versão

controlada individualmente. Assim, é necessário adicionar marcas ('tags' -
em inglês) para que se tenha uma "fotografia" de determinado momento.
Ou seja, o versionamento do conjunto fica a cargo do usuário pois a
numeração gerada pelo sistema de controle de versão não fornece
"alinhamento" aos documentos.

fig. d - Já em sistemas no estilo do SVN, o controle de versão é feito por

cada envio ao servidor. Ou seja, há uma versão global para todos os
documentos. Se você enviar 4 versões do arquivo B enquanto você enviou
apenas 2 versões do A, ambos estão na versão final que é a 4. Perceba que
toda "fotografia" de qualquer momento será sempre uma coluna alinhada
como mostra a figura.

Se o arquivo fosse armazenado diretamente num sistema de arquivos

simples, não haveria histórico, a menos que isso fosse feito manualmente
através de cópias completas dos documentos numa organização (que pode
ou não envolver pastas) que dependerá do desenvolvedor.
fig e - Num sistema de arquivos simples, sem controle de versões, seria
necessário fazer cópias manualmente para manter as versões anteriores, o
que poderia se tornar muito confuso com o tempo conforme o número de
versões aumentam.

Histórico de envio

Muitas vezes, é possível acrescentar comentários no envio das alterações, o

que facilita também uma possível análise do histórico. Geralmente o
relatório com as versões e os comentários de cada envio são chamados de
"histórico" ou "log", e uma análise deste relatório pode facilitar em muitos
aspectos no desenvolvimento do produto.

A documentação do CVS, SVN e outros, recomendam que o comentário do

histórico seja amplo, geral e abstrato, ou seja, que não se limite à
explicação da mudança do código em si, mas sim sobre o que foi mudado
ou acrescentado no conceito ou no funcionamento como um todo. A
mudança do código pode ser analisada através de uma diferença (ou diff)
entre duas versões, portanto o comentário seria útil apenas para explicar a
mudança de forma lógica.

Exemplo prático dessa recomendação: utilize "acréscimo de uma condição

que verifica se existe saldo na conta para não permitir que seja sacado sem
saldo" ao invés de um comentário contendo o próprio código modificado
como:
"+ if (!this.haSaldoNaConta()) { this.proibeSaque() }"

Trabalho em equipe

Sistemas de controle de versão também são convenientes quando diversos

desenvolvedores trabalham sobre o mesmo projeto simultaneamente,
resolvendo eventuais conflitos entre as alterações. A maioria dos sistemas
possui diversos recursos como ramificação e mesclagem de histórico para
auxiliar nessas tarefas.

Para que seja possível o trabalho em equipe, o sistema de controle de

versão pode possuir um mini sistema de controle de usuários embutido ou
pode utilizar algum outro sistema de autenticação separado. Assim, é
possível identificar cada usuário, que geralmente fica protegido por uma
senha pessoal, ou alguma senha criada pelo administrador de sistemas.
No CVS, por exemplo, é possível escolher o método de autenticação a ser
usado, dentre várias opções. No caso do SVN, por exemplo, se ele estiver
rodando via Apache, o controle de usuários poderá ser feito pela
autenticação padrão do Apache. Embora menos comum, é possível também
configurar o SVN para utilizar o usuário do sistema, como os usuários do
Linux ou do Windows.

Mesclagens Otimistas vs Edições Exclusivas

Com relação ao trabalho em equipe num sistema de controle de versão, há

basicamente dois métodos (ou filosofias) relevantes de edição:

* "Optimistic Merges" ("Mesclagens Otimistas") ou "Branch and Merge"

("Ramificando e Mesclando") ou ainda "Copia-modifica-resolve"[2]
* "Exclusive Lock" ("Tranca exclusiva", "Edições exclusivas") ou ainda
"Trava-modifica-destrava"[2])

Nota: a ausência de um sistema de controle de versão, ou seja, o trabalho

direto num sistema de arquivos comum é equivalente ao "Exclusive Lock"
nesse aspecto. Há também alguns sistemas, como o MediaWiki (pelo menos
até a versão 1.8) e. g., que permitem a edição simultânea (sem trancar ou
bloquear o outro) mas que não gerenciam automaticamente os conflitos,
tendo que ser feitos manualmente sempre.

A filosofia "Optimistic Merges" ("Mesclagens Otimistas"), é um método de

conflitos otimista que é geralmente padrão na maioria dos sistemas abertos,
como o SVN e CVS. Essa filosofia presume que os conflitos de edições são
tão pequenos e pontuais — se houver relativa atualização frequente do
repositório por ambos — que a grande maioria das fusões podem ser feitas
de forma automática, restando para fusões manuais somente casos em que
a alteração for feita num mesmo ponto de um mesmo arquivo. A prática
demonstra que essa visão é, na verdade, também a mais realista. O capítulo
#"Demonstração de Mesclagens Otimistas" demonstra como esse método
funciona na prática.

Em contrapartida, numa visão mais pessimista (ou "conservadora"), pode-se

afirmar que, se houver muitas modificações simultâneas sem intervalos
pequenos de atualização mútua num mesmo arquivo, é possível que a fusão
manual se torne tão complicada a ponto de desperdiçar parcialmente ou
totalmente o trabalho de um ou de outro editor usuário do sistema. É por
esse principal motivo que alguns sistemas, geralmente as soluções
comerciais como o ClearCase e o SourceSafe, adotam outro método de
trabalho como padrão: o "Exclusive Lock" ("Tranca exclusiva" ou "Edições
exclusivas"). Esse método consiste basicamente em deixar apenas um
usuário editar um arquivo de cada vez, sendo que este fica bloqueado
enquanto não houver um reenvio (atualização) do editor ao servidor. É
possível mesclagem neste método, mas apenas após a liberação (ou
desbloqueio) do editor. O capítulo #"Edições Exclusivas" ou ausência de um
sistema de controle de versão demonstra como esse método funciona na
prática.

Demonstração de "Mesclagens Otimistas" passo-a-passo

A seguir, é demonstrado em alguns passos, numa edição fictícia, como
funciona o método de "Mesclagens Otimistas". Cada animal personificado a
seguir nas figuras - Pig, Dog e Panda - representam um programador
independente (com ou sem comunicação entre si), que podem estar em
locais físicos separados.
1° passo: atualizando

fig f - todos atualizam sua versão local. (geralmente comando update)

2° passo: desenvolvendo

fig g - todos trabalham simultaneamente, perceba que o Dog e o Panda

estão modificando o mesmo documento porém em locais diferentes (linhas
distintas).
3° passo: submetendo
fig h - Pig e Dog terminaram o trabalho e submetem (commit) as alterações
ao Servidor através do software Cliente. Perceba que o Panda ainda não
terminou o trabalho.
4° passo: necessita atualização

fig i - Panda tenta enviar o arquivo ao Servidor, mas não consegue porque o
Cliente alerta que há uma versão mais atualizada. No caso, é a versão do
documento C que Dog submetera anteriormente.
5° passo: baixando atualização e mesclando

fig j - Nesse caso Panda precisa atualizar (update) sua versão local antes de
submeter as alterações. Geralmente o software Cliente faz uma cópia de
segurança do arquivo local antes de tentar mesclar (merge) as diferenças.
Nesse caso, como na maioria dos casos reais, Panda e Dog modificaram
locais diferentes no arquivo e o Cliente conseguiu mesclar as diferenças
com sucesso. Nesse caso, ele inclui na versão local tanto a alteração de Dog
quanto a de Panda. A maioria dos sistemas analisa as diferenças por linha
alterada, mas é possível que esse bloco seja por parágrafo ou até por letras.
Quando a mesma região do documento é modificada acontece o conflito e
ele precisa ser resolvido manualmente; esse caso será melhor explicado
depois.
6° e último passo: submetendo a versão final
fig k - Depois de mesclado com sucesso, Panda testa para ver se realmente
está tudo OK e simplesmente reenvia (commit) ao Servidor através do
Cliente.

"Edições Exclusivas" ou ausência de um sistema de controle de

versão

No método mais conservador, ou quando se compartilha o mesmo projeto

numa rede diretamente num sistema de arquivos simples, sem um sistema
de controle de versão, alguns arquivos ficam bloqueados para escrita
enquanto estão sendo utilizados. Ainda, um agravante na ausência do
sistema de controle de versão, é que o fluxo de informações pela rede é alto
porque a cada modificação substancial é necessário reenviar o documento
todo e a chance de corromper arquivos também aumenta; o que não
acontece com um sistema de controle de versão, pois cada desenvolvedor
possui uma cópia local do projeto, trabalhando localmente, baixando as
atualizações e enviando as alterações.

fig l - (compare com a fig. f) Perceba a dificuldade em trabalhar em equipe

utilizando um compartilhamento simples de arquivos pela rede. No exemplo
da figura, o desenvolvedor Panda está ocioso enquanto Dog não terminar de
trabalhar com o documento C. Diferentemente, quando se utiliza um
sistema de controle de versões cada desenvolvedor pode trabalhar
tranquilamente em sua cópia local e o sistema fica encarregado de mesclar
o que for necessário de acordo com as mudanças simultâneas.
Mesclagem no método "Edições Exclusivas"

A mesclagem no método "Edições Exclusivas" é ainda possível

desta forma:

1. usuário A dá checkout (ou update).

2. B tenta dar checkout e não consegue porque A está bloqueado.
3. B dá checkout não reservado (sem bloquear).
4. B tenta dar commit (ou checkin), mas não consegue, B fica aguardando
A liberar o lock (bloqueio).
5. A dá commit ou release, liberando a trava.
6. B dá um update & merge (que já cria um lock para ele).
7. B dá commit com a versão mesclada.

Bloqueio de arquivo

Alguns sistemas permitem o bloqueio voluntário de qualquer arquivo.

Alguns sistemas que suportam são o CVS e SVN (a partir da versão 1.2.0),
por exemplo.

A opção de bloquear um arquivo é muito útil nos seguintes casos:

* Quando há trabalho simultâneo num mesmo arquivo de difícil ou

impossível mesclagem.
* Ao editar um arquivo binário (que não permite a mesclagem), como
arquivos compactados, bibliotecas, imagens etc. Não é muito recomendável
trabalhar com arquivos binários num sistema de arquivos, porém muitas
vezes é útil deixar arquivos binários junto do código-fonte ou da
documentação, principalmente em casos em que é difícil gerar esses
arquivos, como imagens, algumas bibliotecas etc.
* Quando há muita dificuldade na comunicação entre os desenvolvedores
e conflitos freqüentes que desperdiçam muito tempo manual de
mesclagem.

Comparação de versões

É possível, na grande maioria dos sistemas de controle de versão (e quando

o tipo de arquivo permite isso), comparar (também chamado de diff ou
diferença) quaisquer versões entre si, enviadas a qualquer tempo. Saber
exatamente o que foi acrescentado, modificado ou excluído em qualquer
ponto dos documentos. Isso permite que seja feito uma análise minuciosa
das alterações desde a criação do projeto até seu estado atual.
Analise esta figura e veja um exemplo prático real de uma diferença entre
duas versões: (também neste link: [1]). Essa diferença é feita pelo software
MediaWiki que exibe a diferença com cores diferentes e símbolos para
facilitar o entendimento. A cor amarela indica que a linha foi retirada, a cor
verde que a linha foi colocada e a cor vermelha indica qual palavra ou
trecho foi modificado dentro da linha. O símbolo (+) indica que foi
acrescentado e o (-) que foi retirado.

Conflitos

É chamado de conflito de edição a situação em que dois ou mais usuários

modificam o mesmo documento no mesmo intervalo de tempo entre o envio
de uma nova versão ao sistema. A chance de conflitos aumentam quando
aumentam o número de usuários utilizando o mesmo conjunto de
documentos. O envio de alterações muito grandes podem também
aumentar a chance de conflito.

Mesclagem

A mesclagem (ou merge em inglês) consiste na aglutinação (ou fusão)

automática de versões através da comparação entre elas, quando há um
conflito de edições simples.

Quando um conflito é direto, ou seja, no mesmo ponto do mesmo

documento e o sistema não conseguiu resolver o conflito automaticamente,
a mesclagem pode ser feita manualmente. Algumas implementações como
o MediaWiki (até a versão 1.8 pelo menos) não possuem o sistema de
"mesclagem", portanto quando há qualquer conflito, mesmo os mais
simples, é necessário resolvê-lo manualmente como descreve a seção
#Resolução manual de conflitos.
Resolução manual de conflitos

Quando dois ou mais desenvolvedores modificam uma mesma região num

documento é necessário resolver o conflito "manualmente". O software de
Cliente fará uma cópia de segurança da sua alteração para que não haja
chance de você perdê-la e depois mostrará o local de conflito. O software
geralmente mostra os conflitos na tela e o desenvolvedor escolhe qual
versão manter. Geralmente quando acontece esse tipo de coisa é porque
houve falha na organização de divisão do trabalho e provavelmente uma
alteração semelhante foi produzida na mesma região.

Ramificações e marcações

Num sistema moderno de controle de versões é possível quebrar a linha do

desenvolvimento em mais de um caminho. Isso pode ser chamado de
ramificação (ramo), braços ou em inglês branches. Isso é muito útil quando
se conquista uma versão estável dos documentos (ou software) ou quando
se quer fazer uma tentativa "não convencional" fora do ramo principal.

Otimização de espaço e velocidade

Geralmente um sistema assim mantém armazenado apenas a primeira

versão e as diferenças entre elas, até formar a última, com o principal
objetivo de economizar espaço. É claro que também existem outras
otimizações que guardam a versão final ou versões recentes para que
algumas operações possam ser feitas de modo mais rápido (utilizando uma
espécie de cache). É possível também, dependendo do sistema e da
configuração, que seja compactado algumas partes do repositório muito
antigas que não estão sendo utilizadas de modo a salvar espaço.

Os sistemas são otimizados para trabalhar com arquivos texto e muitas

vezes não se dão muito bem com arquivos binários. Sistemas mais
modernos trabalham melhor com esse segundo tipo de arquivo, mas ainda
assim de forma pouco satisfatória: tanto pelo alto consumo de espaço
quanto pela dificuldade de se fazer comparação entre uma versão e outra.

Sistemas como o CVS e o SVN recomendam que documentos textos que

necessitam de estilos, formatações especiais, tabelas e figuras, tais como o
arquivo DOC do Microsoft Word que são em binário, sejam gravados em
algum formato texto como o Rich Text Format (RTF), HTML ou XML (com
quebras de linha entre uma tag e outra[3]) porque internamente ele guarda
a informação em texto. Um texto desse tipo não fica tão otimizado quanto
um texto simples, mas ainda assim fica melhor que um arquivo binário.