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

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

No último post  da série controle de versão distribuído com GIT, falamos sobre a filosofia dos controles de versões e as modificações na forma de pensar e trabalhar a partir do git. Neste post será feita uma abordagem mais técnica apresentando o processo de instalação e as primeiras interações com o ambiente git.

Instalação

O git possui pacotes de instalação para diversas plataformas. Podemos instalar o git nos principais sistemas operacionais de duas formas: Utilizando um pacote de instalação pré-compilado para uma determinada plataforma e a segunda obtendo o código fonte e efetuando a compilação. Considero a primeira opção a mais prática aconselhando utilizar o processo de compilação apenas para quando se queira instalar uma versão em especifico que não tenha um pacote compilador.

Para este tutorial, iremos apresentar as instalações nas principais plataformas de mercado (linux, mac os e windows).

Instalando no linux

A forma de instalação no linux vai depender apenas de qual gerenciador de pacotes você está utilizando. O nome do pacote de instalação do git constuma se chamar git-core.

Se estiver utilizando distribuições baseadas no debian, utilizando o comando apt-get é possível rapidamente instalar.

$ sudo apt-get install git-core

Para os usuário de distros baseadas na estrutura fedora, pode-se utilizar o comando yum.

$ sudo yum install git-core

Instalando no mac

No linux podemos instalar o git via instalador gráfico git4osx ou através do macports via linha de comando.

$ sudo port install git-core +svn +doc +bash_completion +gitweb

Note que não é preciso instalar todos os complementos.

Instalando no windows

A instalação no windows é bastante simplificada. O projeto msysGit possui um instalador com procedimentos fáceis para a instalação do git.

Você pode obter o instalador a partir da página do projeto no google code

$ http://code.google.com/p/msysgit

Primeiras configurações

Após concluída a instalação, vamos realizar algumas configurações básicas no git antes de partir para sua utilização. Você vai observar que todos os procedimentos feitos neste tutorial, são realizados na própria linha de comando do SO. Existem algumas ferramentas gráficas que podem atuar como GUI do git. Experimentei algumas e cheguei a conclusão que pela falta de maturidade e muitas vezes simplicidade do git, as vezes se torna mais prático utilizar o core na linha de comando.

Definindo a sua identificação

É importante definir o seu nome de usuário e email pois estas informações sempre serão anexadas aos comandos de commit feitos nos repositórios.

Para configurar estas variáveis, na linha de comando digite o seguinte:

$ git config --global user.name "Rafael Soto"
$ git config --global user.email rafael.soto@gmail.com

Definindo o editor de texto padrão

Sempre que o git precisar de uma entrada de dados do usuário o mesmo vai chamar o editor de texto padrão definido.

Para definir um editor de texto padrão, digite a linha de comando abaixo no seu console:

$ git config --global core.editor smultron

Definindo a ferramenta para realizar diff

Ferramentas de diff  são solicitadas pelo git em momentos de conflitos nas operações de merge. Apesar destes conflitos serem raros no git, é importante ter uma boa ferramenta gráfica definida para solucionar o problema da melhor forma possível. Abaixo segue a linha de comando para definir qual diff utilizar.

$ git config --global merge.tool vimdiff

Verificando as configurações

Você pode verificar todas as suas configurações executando o comando config –list

$ git config --list
user.name=Rafael Soto
user.email=rafael.soto@gmail.com
core.repositoryformatversion=0
filemode=true
bare=false
logallrefupdates=true
...

Iniciando os trabalhos no GIT

Repositórios

Para se criar ou obter um repositório git existem duas possíveis abordagens. A primeira utilizamos quando se deseja criar um novo repositório, neste caso de forma local criamos um novo repositório em branco ou um repositório a partir de um sistemas de arquivos existente. A segunda abordagem é feita através da importação de um repositório em uma máquina remota, no caso do git , chamamos este procedimento de clone.

Para iniciar o aprendizado dos comandos iniciais vamos trabalhar com a abordagem do repositório local. Em um outro momento iremos explorar a forma de trabalho publicando as ações em repositórios remotos através de um exemplo prático utilizando repositórios remotos como o git-hub.

Iniciando o repositório local

Inicialmente vamos criar uma pasta para o repositório

$ mkdir meurepo
$ cd meurepo

Logo em seguida vamos inicializar um novo repositório git a partir do diretório corrente

:/meurepo $ git init

Note que uma pasta .git foi criada no local onde o comando foi executado. Esta é a única pasta criada e utilizada pelo git dentro de todo o seu projeto. De uma forma simplificada, ele realiza a “mágica” de estruturar toda a base de versões do seu projeto nesta pasta. Pronto! Já temos o nosso repositório de controle de versões com todos os serviços fornecidos pelo git disponíveis de forma local.

Executando operações no repositório

Vamos iniciar os trabalhos criando 2 arquivos para explicarmos exemplos de operações no repositório.

:/meurepo $ touch README
:/meurepo $ touch INSTALL

Arquivos criados no diretório de trabalho(working directory) podem estar em dois estados: Tracked ou Untracked. O estado Untracked corresponde a arquivos que foram recentemente criados e estão fora do repositório git. Estes arquivos são vistos pelo git como arquivos não presentes na ultima snapshot de versão e suas modificações não são tratadas pelo mesmo. Arquivos Tracked representam exatamente o oposto, são arquivos que já estão presentes no repositório e suas modificações são rastreadas pelo git.

Para verificar o estado de um arquivo no repositório utilizamos o comando git status, este comando apresenta a situação dos arquivos em relação ao repositório naquele dado momento. Como exemplo vamos verificar o status dos arquivos que acabamos de criar.

:/meurepo $ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#    INSTALL
#    README
nothing added to commit but untracked files present (use "git add" to track)

Os dois arquivos (README e INSTALL) se encontram no estado Untracked, ou seja, como apenas criamos eles e não adicionamos no repositório qualquer modificação feita nos mesmos não vai efetuar nenhuma mudança no estado do repositório.

Para que um arquivo seja inserido no repositório e na próxima versão, o mesmo precisa estar marcado como staged(o detalhamento deste fluxo de trabalho foi tratado na parte 1 deste tutorial). Para adicionar um arquivo na área staged utilizamos o comando git add <arquivo/diretorio>. Vamos adicionar no nosso exemplo apenas o arquivo INSTALL e em seguida vamos verificar o status do repositório.

:/meurepo $ git add INSTALL
:/meurepo $ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#    new file: INSTALL
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#    README

Note que o arquivo INSTALL passa a estar disponível para entrar no próximo commit do repositório e o seu estado é de novo arquivo (new file). Vale observar que o fato de termos adicionado o arquivo, o mesmo não se encontra no repositório apenas pronto para ser realizado o commit. Ao se utilizar o comando add o git congela a situação do arquivo e o deixa pronto para o commit, se modificarmos novamente este arquivo, teremos duas versões para este arquivo, uma que já está pronta para commit e outra que foi modificada depois de já ter marcado o arquivo para o commit. Como exemplo vamos modificar o mesmo arquivo INSTALL antes de realizar o commit e verificar o status do repositório ao final da operação.

:/meurepo $ git echo "CONTEUDO 1" >> INSTALL
:/meurepo $ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#    new file: INSTALL
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#    modified:   INSTALL
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#    README

Observe que agora temos o mesmo arquivo INSTALL com dois estados no repositório. O primeiro representa o arquivo recém criado que foi marcado a ser inserido no repositório e o segundo o arquivo que foi modificado. Mas se nem se quer efetuamos o commit porque o arquivo já possui estado modified ? Ao executar o comando add, o git congelou o estado do arquivo INSTALL e copiou ele para área de staged. A área de staged é o local onde fica armazenado todos os arquivos que irão compor o próximo commit, snapshot ou versão do repositório. Logo em seguida, fizemos uma alteração no arquivo inserindo um conteúdo nele. Como o estado do arquivo foi modificado e ficou diferente do estado do arquivo que foi congelado na área staged do repositório, o git já identificou a mudança e deixou o novo estado do arquivo marcado para inclusão. Podemos adicionar novamente o arquivo a área de staged e a versão que passa a contar do arquivo é a ultima modificada.

:/meurepo $ git add INSTALL
:/meurepo $ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#    new file: INSTALL
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#    README

O próximo passo seria gerar uma nova versão ou snapshot do projeto a partir da operação commit. O commit é a operação responsável por gerar uma nova versão do projeto a partir dos arquivos que foram marcados como staged. Ao executar o comando, o git efetua uma copia de toda a situação dos arquivos incluindo as modificações e as armazena na base de dados com uma versão.

:/meurepo $ git commit -m "Meu primeiro commit"
Created initial commit fd7a2de: Meu primeiro commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 INSTALL

:/meurepo $ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#    README
nothing added to commit but untracked files present (use "git add" to track)

Podemos notar que após efetuar o commit, o arquivo que estava marcado como staged foi enviado para o repositório e a área de staged limpa, restando apenas o arquivo README que se encontra no estado Untracked por não ter sido adicionado ainda.
Mas podemos nos perguntar: Sempre que eu alterar um arquivo ou criar um novo preciso ficar adicionando o mesmo a área de stag? Para responder a esta pergunta o git implementou um parâmetro para o comando commit que permite pular a etapa de adicionar os arquivos a área de staged. Ao se utilizar do argumento -a o próprio git se encarrega de adicionar e realizar o commit automaticamente.
Note que o recurso de staged de arquivos permite um controle maior do que será feito no commit.


:/meurepo $ git add README
:/meurepo $ cat "CONTEUDO 2" >> README
:/meurepo $ git commit -a -m "Meu segundo commit"</pre>

Created commit 4a2fd75: Meu segundo commit
 1 files changed, 1 insertions(+), 0 deletions(-)

:/meurepo $ git status
# On branch master
nothing to commit (working directory clean)

Observe que adicionamos o arquivo README e logo em seguida modificamos ele. No momento em que realizamos o commit com o parametro -a, o git coloca todos os arquivos modicados na área de staged e depois submete eles para o repositório.

Abaixo segue o resumo do fluxo de trabalho apresentado

Para remover o arquivo do repositório utilizamos o comando git rm <arquivo> e em seguida a confirmação da ação com o commit. Note que enquanto o commit da remoção não for feito, o arquivo permanece existente no repositório na sua ultima versão. Podemos por exemplo restaurar ele para o diretório de trabalho. Como exemplo vamos remover o arquivo README.


:/meurepo $ git rm README
:/meurepo $ git status

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#    deleted:    README
#

:/meurepo $ git commit -m "removendo arquivo README"</pre>
Created commit b1800eb: removendo arquivo README
 1 files changed, 0 insertions(+), 1 deletions(-)
 delete mode 100644 README

:/meurepo $ git status
# On branch master
nothing to commit (working directory clean)

Para mover ou renomear os arquivos do repositório utilizamos o comando git mv <arquivo origem> <arquivo destino> e em seguida a confirmação da ação com o commit.
Como exemplo vamos modificar o nome do arquivo INSTALL.

:/meurepo $ git mv INSTALL INSTALL.txt
:/meurepo $ git status

# On branch master
nothing to commit (working directory clean)
~/repositorios/meurepo$ git mv INSTALL INSTALL.txt
~/repositorios/meurepo$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#    renamed:    INSTALL -> INSTALL.txt
#

:/meurepo $ git commit -m "modificando nome arquivo INSTALL"

Created commit 27f465e: modificando nome arquivo INSTALL
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename INSTALL => INSTALL.txt (100%)

:/meurepo $ git status
# On branch master
nothing to commit (working directory clean)

O fluxo executado acima corresponde ao fluxo abaixo


$ mv INSTALL INSTALL.txt
$ git rm INSTALL.txt
$ git add INSTALL
$ git commit -m ""

Chegamos ao final de mais um post. No próximo post iremos abordar o tema BRANCH, apresentando a forma de trabalho a partir de multiplas linhas de desenvolvimento.

Anúncios
Categorias:Tutorial Tags:,
  1. Nenhum comentário ainda.
  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: