Controle de versionamento com Git
-
Upload
raphael-cruzeiro -
Category
Documents
-
view
728 -
download
14
Transcript of 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.
Controle de versionamento distribuido
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.
Controle de versionamento distribuido
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]”
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"
Revertendo mudanças
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
Revertendo mudanças
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
Práticas de versionamento
O branch master é estavel. Nenhum desenvolvimento é feito nele.
Práticas de versionamento
O desenvolvimento ocorre no branch dev.
Práticas de versionamento
Pode-se continuar o desenvolvimento no dev pois o ambiente de homologação é sincronizado apenas com o testing.
Práticas de versionamento
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.
Práticas de versionamento
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.
Práticas de versionamento
O que estiver no master esta sempre pronto para produção.
Dúvidas?