controle de versionamento com git

Controle de versionamento com

Raphael Cruzeiro - 2012

Git?

Git é um software de controle de versionamento criado por Linus Torvalds para ser utilizado no desenvolvimento do kernel do Linux. Cada working directory do Git é um repositório completo, idependente de acesso a rede ou de um servidor central.

Git?

O grande diferencial do Git é a velocidade e a flexibilidade.

Controle de versionamento distribuido

Em um sistema de controle de versionamento distribuido cada desenvolvedor possui uma cópia completa e independente do repositório em sua máquina.


Isto não apenas torna so dados mais seguros quanto a uma eventual perda mas como também facilita em possibilitar que o desenvolvedor possa trabalhar offline aproveitado todos os recursos de um controle de versionamento.

3 estágiosO Git possui 3 estágios principais para os arquivos do seu projeto: commited, modified e staged. Commited significa que os dados estão seguros, salvos no seu banco de dados local. Modified significa que você modificou o arquivo mas ainda não o comitou. Staged significa que o arquivo foi marcado para ir no próximo commit.

3 estágios

Começando a usar Git

Salvando sua identidade:

$ git config --global user.name “Darth Vader”$ git config --global user.email “[email protected]”

mailto:[email protected]


Começando a usar Git

Setando um par de chaves para autenticação:

$ ssh-keygen -t rsa # Cria o par de chaves$ cat ~/.ssh/id_rsa.pub # Mostra a chave pública

Criando um repositório

Para inicializar um repositório Git basta ir na pasta do projeto e rodar o seguinte comando:

$ git init

Adicionando arquivos

Para adicionar os arquivos utilizamos o comando add:

$ git add *.c$ git add README

Adicionando arquivos

Ou para adicionar todos os arquivos:

$ git add .

Ooopss, comitei o que não devia

Para remover um arquivo basta:

$ git rm *.pyc$ git rm imagem.jpg

Ignorando arquivosPara ignorarmos arquivos especificos podemos utilizar o arquivo .gitignore:

.DS_Storeenv*.pyc

Commitando os arquivos

Para commitar os arquvios utilizamos o commando commit:

$ git commit -a -m ‘Initial commit’

A opção -a diz ao git para colocar em stage todos os arquivos modificados ou deletados (novos arquivos ainda não trackeados não são afetados).

Melhores mensagens de commit

Para criar mensagens mais significativas, é recomendado que não se use a opção -m no commit. Desta forma o git ira abrir o vim para que uma mensagem seja digitada:

Melhores mensagens de commit# Please enter the commit message for your changes. Lines starting# with '#' will be ignored, and an empty message aborts the commit.# On branch master# Changes to be committed:# (use "git reset HEAD <file>..." to unstage)## modified: my_source.py#~

Vendo o log do repositórioPara ver o log do repositório basta utilizar o commando log:

$ git logcommit 70d6469847e38ac3cb1691513f2c9f7382f03819Author: Raphael Cruzeiro <[email protected]>Date: Tue Dec 11 15:26:16 2012 -0200

A robot must obey the orders given to it by human beings, except where such orders would conflict with the First Law.

commit 47578edf04262b4958aadf01bc4489958d17d5ebAuthor: Raphael Cruzeiro <[email protected]>Date: Tue Dec 11 15:22:20 2012 -0200

A robot may not injure a human being or, through inaction, allow a human being to come to harm.





Revertendo mudanças

Para reverter o a working copy para um estado anterior podemos utilizar o comando checkout: (os primeiros 4 digitos do hash do commit são o suficiente para identifica-lo)

$ git checkout 4757

Se você lembra como começava a mensagem do commit:

$ git checkout :/"My first b"


Qualquer mudança após utilizar o checkout para voltar para uma revisão anterior cria uma especie de universo paralelo chamado branch. (Falaremos disso mais tarde).

Para voltar ao presente você pode sempre utilizar o comando:

$ git checkout master


Caso você queira reverter a um estado anterior e descartar todo o que veio depois você pode utilizar o seguinte commando:

$ git reset --hard 4757

Corrigindo o último commit

As vezes você faz besteira no seu último commit. Calma, você não precisa sair fazendo reset. Faça um amend!

$ git commit --amend -a

Tá tudo errado!!Suponha que você comitou arquivos que não devia, as mensagens de commit não são apropriadas. O que fazer?

Tá tudo errado!!

$ git rebase -i HEAD~10

Os últimos 10 commits vão aparecer no editor de texto. Você pode trocar as mensagens ou apagar os commits deletando as linhas que os representam.

Tá tudo errado!!

pick 5c6eb73 Arrumei erro de grafíapick a311a64 Removi a conf localpick 100834f Adicionei as imagens

Tá tudo errado!!Substitua o pick com:

edit para marcar um commit para amendreword para mudar a mensagemsquash para fazer um merge com o commit anteriorfixup para fazer um merge com o commit anterior e descartar a mensagem so log

Tá tudo errado!!

Se você marcou algum commit com edit, utilize o seguinte comando para que o git te leve a este commit para fazer amends:

$ git rebase --continue

Quem foi o vi#$%#?

Para ver quem fez cada mudança em um arquivo:

$ git blame my_source.py

Universos paralelos

Branches

Quando se trabalha em um projeto relativamente grande é comum que existam funcionalidades sendo desenvolvidas enquanto outras pessoas trabalham em ajustes de funcionalidades já desenvolvidas.

Branches

Para que seja possivel conciliar o trabalho dessas duas equipes utilizamos branches separados.

Branches

Para criar um branch:

$ git checkout -b experimental # Um branch chamado experimental foi criado.

Branches

Para retornar ao branch master:

$ git checkout master

Multiplayer

Multiplayer

Quando colaboramos em um projeto, geralmente existe um repositório remoto e cada desenvolvedor trabalha no seu próprio repositório local (o que chamamos de fork)

Multiplayer

Para fazer o fork de um repositório basta:

$ git clone [email protected]:inspira_tecnologia/agclick_senai.git

Multiplayer

Para puxarmos do repositório remoto as mudanças enviadas pelos outros desenvolvedores utilizamos o seguinte commando:

$ git pull

Multiplayer

Para pegar especificamente as mudanças no branch master:

$ git pull origin master

Multiplayer

Para enviar os commits do nosso repositório local para o remoto:

$ git push

Multiplayer

Para listar todos os branches remotos:

$ git branch -r

Práticas de versionamento


O branch master é estavel. Nenhum desenvolvimento é feito nele.


O desenvolvimento ocorre no branch dev.


Pode-se continuar o desenvolvimento no dev pois o ambiente de homologação é sincronizado apenas com o testing.


Havendo ajustes, deve se mergear o testing no fix e realizar os ajustes lá. Ao terminar os ajustes o fix deve ser mergeado no dev e no testing.


A versão no testing, passando na homologação deve ser mergeada no master e lá deve ser aplicada uma tag com uma versão.


O que estiver no master esta sempre pronto para produção.

Dúvidas?

controle de versionamento com git

Documents