Git #1 – Por onde começar? | Café com Leite

Tempo de leitura: menos de 1 minuto

Na empresa onde trabalho, todo mês temos uma reunião técnica chamada de “Melhoria continua”. Essa reunião e dividida em duas partes:

Na primeira, abordamos assuntos cotidianos do desenvolvimento do produto, levantamos as necessidades, onde erramos e onde acertamos, funciona como uma retrospectiva.
Na segunda parte, dois dos participantes fazem uma apresentação de mais ou menos 1 hora e meia, sobre uma tecnologia, framework ou qualquer assunto relacionado ao projeto, que possa melhorar o desenvolvimento. O assunto que será apresentado na reunião seguinte, é definido sempre ao fim e os participantes que irão estudar e apresentar são escolhidos (existe um rodízio).

Em uma das rodadas eu e Fabio Colaneri, fomos escolhidos para falarmos sobre Git. Nosso projeto na época era versionado no CVS, e tínhamos vários problemas, principalmente nos malditos merges.

Por onde começar?

Depois de umas duas semanas de estudos e testes, decidimos que nossa apresentação seria uma De/Para do CVS para o GIT. A apresentação que deveria durar 1 hora e meia, durou umas 8 horas… rsrsrs, tivemos que terminar a apresentação no dia seguinte.

Esses dias fazendo uma limpeza nos meus arquivos, encontrei o PPT e decidir escrever sobre essa ferramenta, quem sabe possa ajudar outras pessoas.

Como o assunto é extenso dividirei em três posts, espero que gostem.

Principais diferenças

A maior diferença entre Git e qualquer outro VCS (sistema de controle de versionamento) como SVN e similares, está na forma que o Git trata os dados.

SVN: lista de mudanças por arquivo
GIT: considera que os dados são como um conjunto de snapshots.
- Se nenhum arquivo foi alterado, a informação não é armazenada novamente, apenas um link para o arquivo idêntico anterior que já foi armazenado

Centalizados: CVS e SVN

Possuem um único servidor central que contém todos os arquivos versionados e vários clientes que podem resgatar (check out) os arquivos do servidor.

Distribuidos: GIT, Mercurial e Bazaar

Os clientes não apenas fazem cópias das últimas versões dos arquivos: eles são cópias completas do repositório.
Se um servidor falha, qualquer um dos repositórios dos clientes pode ser copiado de volta para o servidor para restaurá-lo.
O Git garante integridade das informações, tudo possui seu checksum. O mecanismo usado é chamado de hash SHA-1

24b9da6552252987aa493b52f8696cd6d3b00373

Quase Todas Operações São Locais

O Git possui três estados:

consolidado (committed);
modificado (modified);
preparado (staged).

O workflow básico pode ser descrito assim:

Os arquivos são modificados pelo usuário no diretório de trabalho.
O usuário adiciona snapshots desses arquivos na área de preparação.
Por fim, o usuário realiza o commit, retirando os arquivos da área de preparação e os armazenando permanentemente no diretório Git (repositório local).

Instalação

Vá até o site do Git e faça o download da versão apropriada para seu Sistema operacional e instale-o.

Crie um conta em um repositório remoto. Existem vários, os mais conhecidos são:

Configuração

Primeiro, crie sua a identificação, conforme conta criada no repositório remoto:

[code language=”bash”]
$ git config –global user.name “Trololo”
$ git config –global user.email trololo@example.com
[/code]

Nota: Todos os commits no Git utilizam essas informações, e está imutavelmente anexado nos commits que você realiza

Configure um editor e ferramenta para diff de sua preferência:

[code language=”bash”]
$ git config –global core.editor emacs
$ git config –global merge.tool vimdiff
[/code]

Para listar as configurações, use o comando:

[code language=”bash”]
$ git config –list
user.name= Trololo
user.email= trololo@example.com
color.status=auto
color.branch=auto
…
[/code]

Inicializando um repositório

Vá no diretório raiz do seu projeto existente ou onde você deseja criar seu novo projeto e execute:

[code language=”bash”]
$ git init
[/code]

Nota: Esse comando criará um subdiretório chamado .git (contendo um esqueleto de repositório Git).

Crie um arquivo readme.txt no diretório e adicione ele a stage e em seguida commit:

[code language=”bash”]
$ git add readme.txt
$ git commit -m ‘initial project version’
[/code]

Nota: Comando git add, adiciona os arquivo na stage area.
Comando git commit, efetua o commit dos arquivo no repositório local.
Observação: no commit, o comentário é obrigatório (parâmetro “-m” seguindo do comentário).

Para pública as alterações em um repositório remoto (Ex: GitHub), basta executar os comandos:

Lembrete: antes da publicação, será necessário criar o repositório. No exemplo abaixo, será necessário acessar o GitHub e criar o repositório antes de prosseguir.

[code language=”bash”]
$ git remote add origin git@github.com:username/new_repo
$ git push -u origin master
[/code]

Clonando um repositório

Caso já exista um repositório remoto e você queria baixa-lo para contribuir para o projeto, você precisará clona-lo. Para você precisará ter, previamente, as credenciais no repositório remoto.

Clonando um repositório:

[code language=”bash”]
$ git clone git@github.com:edermfl/TestGit.git
[/code]

Esse comando criará um diretório chamado TestGit, já com o subdiretório .git, no local (diretório) onde o comando foi executado.

Todos os dados do repositório remoto serão baixados, pronto para serem editados ou utilizados.

Arquivos monitorados

Arquivos monitorados, são aqueles que estavam no último snapshot. Esses arquivos podem estar em um dos três status abaixo:

inalterados (unmodified)
Modificados (modified)
Selecionados (staged)

Existem também os arquivos não monitorados (untracked), esses normalmente são os novos arquivos criados, que ainda não foram adicionados ao repositório.

Ignorando arquivo

Normalmente em nossos projetos existem aquivos que não precisam ser versionados, arquivo como por exemplo o “.project” que o Eclipse gera.

Para isso é possível criar um arquivo .gitignore na raiz do seu projeto, nesse aquivo, podemos informar ao Git todos os aquivos que não devem ser versionados.

Padrão utilizado para escrita do arquivo:

Linhas em branco ou iniciando com # são ignoradas.
Padrões glob comuns funcionam.
Você pode terminar os padrões com uma barra (/) para especificar diretórios.
Você pode negar um padrão ao iniciá-lo com um ponto de exclamação (!).

Exemplo Arquivo:

[code language=”bash”]
$ cat .gitignore
.project
*.[oa]
*~
[/code]

Nota: glob são como expressões regulares simples que os shells usam.

É isso aí pessoal, no próximo post falarei como usar efetivamente o Git, baixando e subindo commit para o repositório remoto.

Se gostou, dá uma curtida ou comente.

Abraços.