Git é um sistema de controle de versão criado por Linus Torvalds para o desenvolvimento do kernel Linux. Cada diretório de trabalho do Git é um repositório completo e independente. Git permite que desenvolvedores trabalhem offline e cada um tenha uma cópia completa e independente do repositório.

1. Controle de
versionamento com
Raphael Cruzeiro - 2012

2. 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.

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

4. 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.

5. 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.

6. Controle de versionamento
distribuido

7. 3 estágios
O 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.

8. 3 estágios

9. Começando a usar
Git
Salvando sua identidade:
$ git config --global user.name “Darth Vader”
$ git config --global user.email “vader@theempire.com”

10. 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

11. Criando um
repositório
Para inicializar um repositório Git basta ir na pasta do
projeto e rodar o seguinte comando:
$ git init

12. Adicionando
arquivos
Para adicionar os arquivos utilizamos o comando add:
$ git add *.c
$ git add README

13. Adicionando
arquivos
Ou para adicionar todos os arquivos:
$ git add .

14. Ooopss, comitei o
que não devia
Para remover um arquivo basta:
$ git rm *.pyc
$ git rm imagem.jpg

15. Ignorando arquivos
Para ignorarmos arquivos especificos podemos utilizar o
arquivo .gitignore:
.DS_Store
env
*.pyc

16. 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).

17. 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:

18. 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
#
~

19. Vendo o log do repositório
Para ver o log do repositório basta utilizar o commando log:
$ git log
commit 70d6469847e38ac3cb1691513f2c9f7382f03819
Author: Raphael Cruzeiro <raphaelcruzeiro@raphaelcruzeiro.com>
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 47578edf04262b4958aadf01bc4489958d17d5eb
Author: Raphael Cruzeiro <raphaelcruzeiro@raphaelcruzeiro.com>
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.

20. 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"

21. 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

22. 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

23. 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

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

25. 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.

26. Tá tudo errado!!
pick 5c6eb73 Arrumei erro de grafía
pick a311a64 Removi a conf local
pick 100834f Adicionei as imagens

27. Tá tudo errado!!
Substitua o pick com:
edit para marcar um commit para amend
reword para mudar a mensagem
squash para fazer um merge com o commit anterior
fixup para fazer um merge com o commit anterior e
descartar a mensagem so log

28. 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

29. Quem foi o vi#$%#?
Para ver quem fez cada mudança em um arquivo:
$ git blame my_source.py

30. Universos paralelos

31. 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.

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

33. Branches
Para criar um branch:
$ git checkout -b experimental # Um branch
chamado experimental foi criado.

34. Branches
Para retornar ao branch master:
$ git checkout master

35. Multiplayer

36. 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)

37. Multiplayer
Para fazer o fork de um repositório basta:
$ git clone git@bitbucket.org:inspira_tecnologia/agclick_senai.git

38. Multiplayer
Para puxarmos do repositório remoto as mudanças
enviadas pelos outros desenvolvedores utilizamos o
seguinte commando:
$ git pull

39. Multiplayer
Para pegar especificamente as mudanças no branch
master:
$ git pull origin master

40. Multiplayer
Para enviar os commits do nosso repositório local para o
remoto:
$ git push

41. Multiplayer
Para listar todos os branches remotos:
$ git branch -r

42. Práticas de versionamento

43. Práticas de versionamento
O branch master é estavel. Nenhum desenvolvimento é
feito nele.

44. Práticas de versionamento
O desenvolvimento ocorre no branch dev.

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

46. 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.

47. 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.

48. Práticas de versionamento
O que estiver no master esta sempre pronto para
produção.

49. Dúvidas?