Início > Tutorial > Tutorial Controle de Versão Distribuído: GIT – Parte 1

Tutorial Controle de Versão Distribuído: GIT – Parte 1

Olá amigos.

Estamos iniciando as atividades deste novo blog com uma série de tutoriais sobre o controle de versão distribuído GIT.

A algumas semanas atrás tive o primeiro contato com o git e posso confessar que fiquei impressionado com a sua filosofia de trabalho e principalmente a qualidade dos resultados ao se realizar trabalhos complexos com gerência de branchs de desenvolvimento e merge de versões.

Nesta primeira parte da série de tutoriais sobre o git iremos falar rapidamente sobre ferramentas para controle de versão e nova filosofia de trabalho proposta. Vamos ao que interessa!

O que é um controle de versão ?

Controle de versão é um sistema com a capacidade de armazenar todas as modificações aplicadas a um arquivo ou a um conjunto de arquivo ao longo do tempo sendo possível a qualquer instante obter uma determinada versão anterior dos dados.  A partir de uma ferramenta como esta, é possível recuperar a situação de um determinado sistema em um determinado instante no tempo, garantir a harmonia no desenvolvimento colaborativo com diversos desenvolvedores codificando simultaneamente, gerenciar baselines e releases de produtos dentre muitas outras facilidades ou necessidades existentes na atual situação do desenvolvimento de software.

Abaixo iremos descrever 3 paradigmas de controle de versão finalizando no conceito do controle de versão distribuído.

Controle de versão local

Muitas pessoas já tinham o habito de versionar as versões dos seus arquivos em um procedimento manual localmente nas suas máquinas. Para cada modificação feita no projeto uma nova pasta com o timestamp era criada contendo a copia de todo o conteúdo para ser modificado. Este procedimento é super comum porque ele é bastante simples e fácil de se realizar mas muito complicado de se manter e garantir integridade, além é claro de não permitir o trabalho simultâneo de várias pessoas. Imaginem se o usuário por algum motivo se distrai e executa uma alteração na pasta errada? Seria abusar demais da sorte visto que é um ser humano que está realizando o versionamento.

Controle de versão centralizado

Os desenvolvedores precisavam encontrar uma forma de trabalhar juntos no mesmo conjunto de arquivos. Este desafio originou o que chamamos de controle de versão centralizado, bastante popular até os dias atuais no mercado de desenvolvimento de software. Sistemas para controle de versão centralizados como CVS, SVN possuem na figura do servidor um local central onde estão presentes todos os arquivos de um determinado projeto. Conectados a estes servidores estão os desenvolvedores que a partir de um processo denominado check-in e check-out conseguem realizar sincronismo com o repositório que versiona toda a operação.

Este modelo oferece uma série de vantagens em relação ao modelo local de versionamento.  Por exemplo, todo desenvolvedor possui a visão global em relação ao que os demais desenvolvedores estão produzindo sem nenhum tipo de coordenação entre eles.  Como tudo está centralizado é possível realizar trabalhamos simultâneos estando os desenvolvedores em locais geográficos distintos sem a preocupação individual com a integridade dos dados.

Mesmo parecendo ser um modelo bastante interessante o mesmo possui uma série de deficiências. A primeira e obvia seria possuir um único ponto de falha. Se o servidor de versão ficar fora do ar por algumas horas, nenhum integrante da equipe poderá colaborar com o desenvolvimento estando os mesmos dependentes deles para prosseguir o trabalho. Mesmo trabalhando de forma local e depois enviando os arquivos, muitas vezes se faz necessário realizar a necessidade de versões para garantir pontos de controles nos trabalhos. E no pior caso se os dados do servidor for corrompido por algum motivo aleatório mesmo tendo copias locais em cada máquina dos desenvolvedores, concordo que os dados serão recuperados mas pergunto. E as versões? Se as mesmas não fossem importantes não precisaríamos de um sistema para controle de versão e sim um grande servidor de backup de arquivos.

Os dois modelos descritos acima sofrem do mesmo problema. Se os dados no servidor de controle de versão for corrompido todas as versões serão perdidas.

Controle de versão distribuído

O grande diferencial aplicado pelos sistemas de versão distribuído é a ausência da figura central do servidor como ponto concentrador. No sistema de versão distribuído os clientes não efetuam check-out para obter a ultima revisão do conjunto de arquivos para sua máquina e sim para obter todo o repositório com todas as suas revisões. Caso todos os servidores apresentem falha e todo o repositório seja perdido, como todos os clientes possuem uma cópia do repositório qualquer um deles pode restaurar o repositório no servidor pois os mesmos possuem nas suas máquinas todo o histórico de revisão. É como se cada estação cliente se tornasse um nó de uma grande rede da ferramenta de controle de versão. Como todos os clientes se tornam nós da rede não se faz preciso a todo momento possuir conectividade com o servidor para trabalhar. Todo o versionamento é feito na sua própria máquina e futuramente é possível sincronizar com um nó servidor. Imagine, fazer commit na sua própria máquina sem ter internet dentro de um avião?

Outro ponto bastante positivo é que pelo fato de possuir todas as revisões na máquina local se torna possível realizar o processo de merge revisão por revisão com a tranquilidade de não sobrecarregar o servidor e reduzir a probabilidade de conflitos.  Mais a frente, nos próximos tutoriais, iremos ver na prática como isso funciona. Por hora acreditem, o merge no git é algo bastante evoluído em comparação as ferramentas anteriores.

História do GIT?

O git nasceu a partir de uma motivação do projeto do kernel  do linux a partir das deficiências apresentadas pela ferramenta que estava em uso antes da sua substituição pelo git.  O projeto do kernel do linux tem como principal característica um extenso escopo de tarefas e um processo de colaboração extremo visto que é um dos mais antigo projeto de software livre. No inicio(1991 – 2002) o projeto era mantido a partir de arquivos de patch e compactações. A partir de 2002, o projeto começou a utilizar um sistema de controle de versão distribuído chamado BitKeeper.

Em 2005, a relação entre os desenvolvedores do projeto kernel do linux e a empresa desenvolvedora do BitKeeper foi quebrada e o sistema passou a não ser mais utilizado pela comunidade.  Este evento motivou a comunidade desenvolvedora(em especial Linus Torvalds, pai do linux) a desenvolver o seu próprio sistema de controle de versão baseado em lições aprendidas com a ferramenta anterior. Este novo projeto tinha como requisitos: Velocidades, Simplicidade, Suporte robusto ao desenvolvimento paralelo(projetos com milhares de branchs), totalmente distribuído, capaz de tratar projetos de largas dimensões como por exemplo o projeto do kernel do linux dentro outros.

Em 2005 o projeto atingiu um nível de maturidade aceitável e foi lançado como livre distribuição. Apesar de ser um sistema com uma idade considerável, o GIT começou a se popularizar nos últimos anos principalmente em projetos de software livre. Em destaque podemos destacar o portal git-hub que assume o papel de repositório de projetos de código abertos baseado no git. Para quem não possui um servidor git disponível uma das melhores opções para trabalhar com o mesmo seria criar um projeto no git-hub.

Como o git funciona?

Então como o git funciona? O que muda para a forma tradicional de trabalhar com sistemas de controle de versão?  Para aprendermos a trabalhar com o git, devemos primeiramente esquecer de tudo que aprendemos com controles de versões subversion, cvs, source safe e outros. Apesar das interfaces de administração serem bastante parecidas com as dos outros sistema, o git trabalhar dentro de um paradigma diferente. Entendendo essas diferenças iremos poupar bastante tempo com enganos futuros ao se utilizar do git.

Snapshots e não diff

Uma das grandes diferenças entre o git e os demais sistemas de controle de versão é a forma como o git trata os arquivos. Conceitualmente, todos os sistemas de controle de versão armazenam o arquivos e todas as modificações aplicadas a este arquivo durante o tempo.

O git não trabalha dentro deste conceito, ao invés de armazenar apenas as mudanças, ele armazena um snapshot ou fotografia da situação de todo o sistema de arquivo criando uma espécie de mini-sistemas de arquivos. Todas vez que efetuamos uma operação no git o mesmo obtém uma fotografia de como todos os seus arquivos eram naquele instante e armazena a referência para esta fotografia. Para ser eficiente,  se um determinado arquivo não sofreu modificação, o git não armazena ele novamente, o mesmo cria um link para o arquivo não modificado numa fotografia anterior. Por estas características o git é considerado um mini sistema de arquivos capaz de armazenar diversas versões ou fotografias.

Trabalhe localmente sem stress

A maioria das operações no git são realizadas localmente na estação de trabalho sem necessidade de recuperar informações de uma outra estação ou servidor. Esta é uma grande diferença do git, como o usuário possui todas as versões do repositório localmente, a maioria das operações são realizadas de forma instantânea na própria estação poupando bastante tempo e consumo de recursos de rede visto que os tradicionais sistemas precisam se comunicar constantemente a cada operação.

Vamos ao exemplo, para visualizar o histórico do projeto ou até mesmo as diferenças entre duas versões, o git não precisa ir no servidor para obter e apresentar o histórico. A informação sempre é obtida a partir do repositório local tendo os resultados de forma instantânea sem consumo de recursos do servidor e nem da rede.  Sem contar nos momentos onde não temos conectividade mas precisamos adiantar o trabalho! Com os servidores tradicionais teríamos que esperar uma oportunidade de conexão com a internet ou VPN para podermos dar prosseguimento aos trabalhos.

Git é integro

Tudo no git é aplicado a processos de check-sum, ou seja, não é possível realizar modificações ou até mesmo corromper arquivos sem que o git perceba.  Toda referencia entre arquivos e versões tem como chave o hash do arquivo referenciado, ou seja, qualquer modificação é percebida e a integridade é garantida.

Os 3 estados fundamentais

Este é o principal conceito que deve ser entendido para se aprender a trabalhar com o git corretamente.  O git possui 3 principais estados os quais os arquivos pertencentes ao projeto podem estar marcados: commited, modified, staged. Arquivos no estado commited indicam que o mesmo está armazenado devidamente no repositório local; Modified são arquivos modificados mas que ainda não foram enviados para o repositório local; staged corresponde a arquivos que foram modificados e marcados(stag) para serem enviados no próximo snapshot do repositório ou próximo commit. Abaixo segue o esquema dos estados e locais onde são armazenados os arquivos.

O diretório git é o local onde o git armazena todos os metadados e objetos da base de dados do repositório. Esta é a parte mais importante de um projeto git e é criado no momento onde se inicializa um novo repositório ou efetua uma operação de clone de um outro computador. O diretório de trabalho possui uma estrutura de arquivos de uma determinada versão ou snapshot. Esta estrutura é descompactada do diretório git para o diretório de trabalho e é o local que será utilizado para modificar os arquivos do repositório. A área de stag é representada por um arquivo dentro do diretório git e possui uma relação de arquivos modificados e marcados para serem inseridos na próxima versão(commit).

Em resumo o fluxo de trabalho do git é simplificado e trabalha através do seguinte processo:

1- Usuário modifica um arquivo no diretório de trabalho local;

2- Usuário efetua o stag dos arquivos que deseja inserir no próximo snapshot ou versão;

3- Usuário efetua o commit transferindo os arquivos presentes na área de stag para o repositório local do git. Neste momento um novo snapshot é criado verificando as modificações na lista de arquivos taged.

Note que diferente dos sistemas sistemas tradicionais, apenas é feito o commit de arquivos que estiverem na área taged do repositório git local.

Chegamos ao final do primeiro post da série de tutoriais sobre o sistema para controle de versão git. No próximo post iremos abordar a parte prática como instalação e utilizações básicas.

* Este post foi baseado no livro pro-git.

Anúncios
Categorias:Tutorial Tags:,
  1. 5 de março de 2012 às 16:52

    Fala rafikdabahia, beleza?!
    Ótimo post cara, eu estava com um pouco de dificuldade em entender o Stag do GIT, e seu post foi muito esclarecedor 🙂

    Grande abraço

  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: