GIT: Ferramenta para controle e versionamento de projetos

O que segue a justiça e a beneficência achará a vida, a justiça e a honra. (Provérbios 21:21)

GIT é um programa bastante útil para gerenciamento de fluxos de trabalho em projetos de desenvolvimento. Por exemplo: Em um equipe de 3 desenvolvedores, em que cada um é responsável por uma funcionalidade específica do sistema, é necessário que haja um controle do que cada um está fazendo. Por exemplo: Que arquivo cada um alterou? Seria interessante que os membros desta equipe não consiga editar um mesmo arquivo ao mesmo tempo. 

Para resolver problemas assim é que foi criado o GIT. Git é um programa de versionamento criado e mantido inicialmente por Linus Torvald -- O pai do Linux. Foi elaborado como sendo controle de versões do sistema operacional LINUX e armazenamento do histórico de atualizações, de tal forma que era possível, por exemplo, recuperar as alterações feitas em determinada versão, identificar os usuários responsáveis por determinadas alterações, etc.

Antes de partir para a prática, é muito importante obter um pouco de teoria:

Imaginemos que tenhamos um fluxo de trabalho normal chamada A, que seria o site de produção, onde é feita a manutenção do sistema. Aí, voçê cria um fluxo paralelo, chamado B, que representa a criação de alguma nova funcionalidade. Daí, A e B seguem paralelos na linha do tempo. Só que, quando B está concluído, voçê deve juntar as alterações de B e as alterações de A. Pois, B não tem as atualizações de A e vice-versa. Então, o que voçê faz: Primeiro adiciona o que voçê fez no A em B, e depois o contrário. Neste caso, A e B são branchs (ramificações do projeto) e o cruzamento ou a equivalência de A e B é chamado de MERGE, que traz a funcionalidade nova em A mantendo o que já foi feito. Isto está bem ilustrado na figura abaixo: 

Pois bem, é quase isso o que faremos no exemplo seguinte: Criamos 3 repositórios (Cada repositório é um diretório onde fica cada BRANCH), sendo um repositório central (Não tem arquivos, apenas armazena informações do fluxo principal), um físico (Fluxo principal) e outro do usuário. Para começar, crie um diretório feito unicamente para fazer os testes. Defina de antemão, quais serão os diretórios utilizados (Um físico, um de usuário e outro central). Mas, crie apenas o diretório físico. 

Por exemplo, no meu caso caso, está assim a estrutura de diretórios:

 

  REPOSITORIO=/home/teste/git-projetos/repo/
         DIRETORIO_FISICO=/home/teste/git-projetos/repo-fisico/
         DIRETORIO_USUARIO=/home/teste/git-projetos/repo-user/

 

Porém, eu tinha criado apenas o diretório físico. 

O esquema que será feito é o seguinte: O usuário apenas poderá fazer alterações no seu diretório (DIRETORIO_USUARIO). Em seguida, caso as alterações já tenham sido feitas, ele pode subir as mesmas para o repositório central (REPOSITORIO). Daí, estas alterações são replicadas para  DIRETORIO_FISICO, que representa o diretório de produção, por exemplo. 

 

Pra começar instale o git pelo comando, caso esteja usando linux fedora

yum install git

 

Do contrário, verifique no site abaixo (Como baixar e instalar no seu SO específico).

http://git-scm.com/downloads

Primeiramente,  vá pela linha de comando, em DIRETORIO_FISICO, definido inicialmente:

 

git init

 

 

Com este comando, voçê instancia o git para seu projeto em particular. Se não tiver nada, crie um arquivo neste diretório. Se tiver, apenas digite "git status".

Note que há uma mensagem +/- assim:

 

# On branch master
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
# teste.php
nothing added to commit but untracked files present (use "git add" to track)

 

Pois bem, isto indica que há uma diferença entre o que está no diretório físico e o que consta na referência do seu BRANCH. Ou seja, no seu BRANCH não consta nada. Se quizer, voçê pode criar, para um mesmo diretório físico, vários BRANCHS, mas, como padrão, só é usado o BRANCH master, que é a ramificação usada neste diretório. Para atualizar seu BRANCH, execute o seguinte comando:

 

git add -A

 

 

git commit -am "Gerando primeiro commit"

 

Com a primeira instrução acima, voçê adicionou o arquivo recém-criado ao BRANCH corrente. E com a segunda, voçê passou as alterações do diretório físico ao BRANCH.  O primeiro é pra passar o arquivo ao BRANCH, o segundo é passar o conteúdo do arquivo ao BRANCH. O conteúdo e o nome do arquivo referenciado são guardados pelo BRANCH. 

 

Agora, iremos criar um repositório central, que armazenará todas as atualizações consolidadas do projeto:

 

git clone --bare DIRETORIO_FISICO REPOSITORIO

 

Como voçê viu,  com a opção --bare, o repositório não conterá arquivos físicos, apenas os BRANCHS do repositório e suas referências. Isto porque teoricamente, ninguém irá editar ou mexer neste repositório.

Depois, é necessário dizer ao DIRETORIO FISICO que toda alteração feita irá para o REPOSITORIO e que, antes de subir qualquer coisa para lá, é preciso antes baixar alterações que possam ser feitas lá.

 

git remote add   -m master -t master -f origin  REPOSITORIO

 

Com o comando acima, o repositório central será apelidado de 'origin' e que os BRANCH master local irá se comunicar com o BRANCH master do repositório central.

Faça qualquer alteração no diretório físico e execute o comando COMMIT 

 

git commit -am "Segundo commit"

 

Note que havia uma diferença entre o que está no seu diretório físico e o que está no seu BRANCH do diretório físico. Com o segundo commit, acaba-se esta diferença, pois, voçê sobe alterações para o BRANCH. Após o BRANCH estar atualizado, voçê deve verificar se não há atualizações por parte do seu repositório central e subir atualização do BRANCH para o repositório central. 

 

git pull origin master

 

 

git push

 

 

Voçê acabou de subir alterações do teu BRANCH local para o BRANCH remoto do repositório central.  O comando PULL faz com que o BRANCH local puxe alterações do BRANCH remoto, cruzando-os pra ver se não dá conflito. Isto é o que chamamos de MERGE. 

Agora crie um repositório de usuário, como cópia do repositório central.

 

git clone  REPOSITORIO DIRETORIO_USUARIO

 

Agora, em seu repositório de usuário, voçê vai criar um arquivo qualquer e subí-lo ao seu BRANCH local:

 

git add ARQUIVO

 

 

git commit -am "Comit de diretório local"

 

 

git pull origin master

 

 

 

git push -u origin master

 

Após voçê ter subido alterações ao repositório central, acesse o DIRETORIO_FISICO.  Verifique se há atualizações por parte do repositório central -- Com certeza há. Observe que o arquivo criado no DIRETORIO_USUARIO já veio no seu DIRETORIO_FISICO. 

 

git pull origin master

 

Como visto, o GIT é uma ferramenta excelente para controle de versionamento e cruzamento de fluxos de trabalho num só fluxo consolidado. 

Em alguns casos, quando se executa o comando PULL, pode ocorrer de haver algum conflito. Neste caso, execute "git mergetool", escolha o editor de sua preferência e corrija o possível conflito. Faça o commit e teste todas as funcionalidades. 

Se quizer visualizar o histórico de commits em um dado repositório, digite "git log".

Observe que cada atualização (commit) tem um identificador único. Como demonstrado abaixo

 

commit 5db02604d00739ccafd295654c3e7a0d8acb0ac7
Author: Wagner Nunes 
Date:   Fri Mar 7 08:59:22 2014 -0300

    Comitando criação de arquivo vazio

 

Se voçê digitar "git reset IDENTIFICADOR_UNICO", o branch voltará ao estado em que estava neste commit. Aí, para replicar esta alteração no seu diretório, é só digitar "git checkout  -A", ou "git checkout ARQUIVO". -A é uma opção que indica que todos os arquivos vão estar equivalentes ao que está no BRANCH. 

Espero que voçê tenha entendido e gostado desta postagem. 

Caso tenha alguma sugestão, não deixe de incluir em seu comentário.

 

Caso queira saber um pouco mais e queira explorar esta ferramenta, sugiro o seguinte link, que é o da documentação oficial da ferramenta:

http://git-scm.com/doc