Uma breve introdução ao funcionamento do git. Não são explicados os comandos com detalhes, mas sim como o git lida com a estrutura de commits. Obs. Inclui notas nos slides para facilitar o entendimento.

1. gitUma breve
Introdução
Andrew Kurauchi (kurauchi@ime.usp.br)

2. GI ?+O que é o git?

3. Controle
deVersões
O git é um sistema de controle de versões.
Ele pode ser utilizado para gerenciar as modificações em um código, texto, etc. ao longo do tempo.

4. ControledeVersões
O git, assim como muitos outros sistemas de controle de versão foi feito inicialmente para ser utilizado por linha de
comandos.
Ele é implementado como um “mini sistema de arquivos” com muitas outras capacidades (histórico, etc).
Além disso, diferentemente do SVN ou outros sistemas, é distribuído e local, ou seja, sempre temos uma cópia do
repositório (local onde está guardado o histórico de mudanças) na nossa máquina. Veremos mais sobre isso
adiante.

5. ControledeVersões
+ Linha de comandos
O git, assim como muitos outros sistemas de controle de versão foi feito inicialmente para ser utilizado por linha de
comandos.
Ele é implementado como um “mini sistema de arquivos” com muitas outras capacidades (histórico, etc).
Além disso, diferentemente do SVN ou outros sistemas, é distribuído e local, ou seja, sempre temos uma cópia do
repositório (local onde está guardado o histórico de mudanças) na nossa máquina. Veremos mais sobre isso
adiante.

6. ControledeVersões
+ Linha de comandos
+ “Sistema de arquivos”
O git, assim como muitos outros sistemas de controle de versão foi feito inicialmente para ser utilizado por linha de
comandos.
Ele é implementado como um “mini sistema de arquivos” com muitas outras capacidades (histórico, etc).
Além disso, diferentemente do SVN ou outros sistemas, é distribuído e local, ou seja, sempre temos uma cópia do
repositório (local onde está guardado o histórico de mudanças) na nossa máquina. Veremos mais sobre isso
adiante.

7. ControledeVersões
+ Linha de comandos
+ “Sistema de arquivos”
+ Distribuído - Local
O git, assim como muitos outros sistemas de controle de versão foi feito inicialmente para ser utilizado por linha de
comandos.
Ele é implementado como um “mini sistema de arquivos” com muitas outras capacidades (histórico, etc).
Além disso, diferentemente do SVN ou outros sistemas, é distribuído e local, ou seja, sempre temos uma cópia do
repositório (local onde está guardado o histórico de mudanças) na nossa máquina. Veremos mais sobre isso
adiante.

8. Comousar
git?o
Provavelmente você encontrará problemas em algum momento utilizando o git. Por esse motivo preferi não me
ater tanto a como usá-lo com muitos detalhes (parâmetros, todos os comandos, etc).

9. Como
funciona
git?o
Ao invés disso veremos como é o seu funcionamento básico.
Após essa apresentação você deverá ser capaz de entender os comandos com mais detalhes. Essas explicações
podem ser encontradas facilmente na internet.

10. Commit
Para isso precisamos inicialmente entender o que é um commit.
Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do
commit e os armazena no repositório.
Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s)
para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.

11. Commit
estado
Para isso precisamos inicialmente entender o que é um commit.
Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do
commit e os armazena no repositório.
Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s)
para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.

12. Commit
estado nome
Para isso precisamos inicialmente entender o que é um commit.
Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do
commit e os armazena no repositório.
Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s)
para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.

13. Commit
estado SHA1
Para isso precisamos inicialmente entender o que é um commit.
Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do
commit e os armazena no repositório.
Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s)
para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.

14. Commit
estado
pais
SHA1
Para isso precisamos inicialmente entender o que é um commit.
Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do
commit e os armazena no repositório.
Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s)
para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.

15. Commit
estado
pais autor
SHA1
Para isso precisamos inicialmente entender o que é um commit.
Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do
commit e os armazena no repositório.
Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s)
para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.

16. Commit
estado
pais autor
etc…
SHA1
Para isso precisamos inicialmente entender o que é um commit.
Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do
commit e os armazena no repositório.
Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s)
para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.

17. Working
directory
Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits
e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se
encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados
inicialmente ao índice (staging area).
!
Alguns comandos:
- git init: cria o repositório
- git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory
- git add: adiciona um arquivo novo/modificado no índice
- git reset: retira um arquivo do índice (cuidado com esse comando)
- git commit: cria o commit com as modificações encontradas no índice.

18. Working
directory
Index
(staging
area)
Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits
e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se
encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados
inicialmente ao índice (staging area).
!
Alguns comandos:
- git init: cria o repositório
- git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory
- git add: adiciona um arquivo novo/modificado no índice
- git reset: retira um arquivo do índice (cuidado com esse comando)
- git commit: cria o commit com as modificações encontradas no índice.

19. Working
directory
Index
(staging
area)
.git
(repositório)
Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits
e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se
encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados
inicialmente ao índice (staging area).
!
Alguns comandos:
- git init: cria o repositório
- git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory
- git add: adiciona um arquivo novo/modificado no índice
- git reset: retira um arquivo do índice (cuidado com esse comando)
- git commit: cria o commit com as modificações encontradas no índice.

20. Working
directory
Index
(staging
area)
.git
(repositório)
Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits
e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se
encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados
inicialmente ao índice (staging area).
!
Alguns comandos:
- git init: cria o repositório
- git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory
- git add: adiciona um arquivo novo/modificado no índice
- git reset: retira um arquivo do índice (cuidado com esse comando)
- git commit: cria o commit com as modificações encontradas no índice.

21. Working
directory
Index
(staging
area)
.git
(repositório)
git init
Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits
e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se
encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados
inicialmente ao índice (staging area).
!
Alguns comandos:
- git init: cria o repositório
- git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory
- git add: adiciona um arquivo novo/modificado no índice
- git reset: retira um arquivo do índice (cuidado com esse comando)
- git commit: cria o commit com as modificações encontradas no índice.

22. Working
directory
Index
(staging
area)
.git
(repositório)
git checkout
git init
Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits
e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se
encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados
inicialmente ao índice (staging area).
!
Alguns comandos:
- git init: cria o repositório
- git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory
- git add: adiciona um arquivo novo/modificado no índice
- git reset: retira um arquivo do índice (cuidado com esse comando)
- git commit: cria o commit com as modificações encontradas no índice.

23. Working
directory
Index
(staging
area)
.git
(repositório)
git checkout
git init
git add
Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits
e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se
encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados
inicialmente ao índice (staging area).
!
Alguns comandos:
- git init: cria o repositório
- git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory
- git add: adiciona um arquivo novo/modificado no índice
- git reset: retira um arquivo do índice (cuidado com esse comando)
- git commit: cria o commit com as modificações encontradas no índice.

24. Working
directory
Index
(staging
area)
.git
(repositório)
git checkout
git init
git add
git reset
Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits
e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se
encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados
inicialmente ao índice (staging area).
!
Alguns comandos:
- git init: cria o repositório
- git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory
- git add: adiciona um arquivo novo/modificado no índice
- git reset: retira um arquivo do índice (cuidado com esse comando)
- git commit: cria o commit com as modificações encontradas no índice.

25. Working
directory
Index
(staging
area)
.git
(repositório)
git checkout
git init
git add
git reset
gitcommit
Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits
e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se
encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados
inicialmente ao índice (staging area).
!
Alguns comandos:
- git init: cria o repositório
- git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory
- git add: adiciona um arquivo novo/modificado no índice
- git reset: retira um arquivo do índice (cuidado com esse comando)
- git commit: cria o commit com as modificações encontradas no índice.

26. Working
directory
Index
(staging
area)
.git
(repositório)
git checkout
git init
git add
git reset
gitcommit
Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits
e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se
encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados
inicialmente ao índice (staging area).
!
Alguns comandos:
- git init: cria o repositório
- git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory
- git add: adiciona um arquivo novo/modificado no índice
- git reset: retira um arquivo do índice (cuidado com esse comando)
- git commit: cria o commit com as modificações encontradas no índice.

27. Trabalhando
comcommits
reposi
notório
Veremos agora como os commits se organizam no repositório e como é possível manipulá-los.

28. DAG
Os commits se organizam em forma de um DAG

29. Directed
Acyclic
Graph
DAG: Grafo Acíclico Dirigido

30. A
Tempo
HEADmaster
Nesse grafo os commits são representados por vértices e as arestas representam a relação pai-filho (nesse
exemplo, A é pai de B e B é pai de C).
Além disso temos um apontador para a cabeça (último commit) da árvore. Esse apontador é chamado por padrão
de “master”. Temos também um “apelido” (alias) para a cabeça: HEAD.
Para boa parte das operações que executaremos o que importa é para onde o HEAD está apontando.

31. A B
Tempo
HEADmaster
Nesse grafo os commits são representados por vértices e as arestas representam a relação pai-filho (nesse
exemplo, A é pai de B e B é pai de C).
Além disso temos um apontador para a cabeça (último commit) da árvore. Esse apontador é chamado por padrão
de “master”. Temos também um “apelido” (alias) para a cabeça: HEAD.
Para boa parte das operações que executaremos o que importa é para onde o HEAD está apontando.

32. A B C
Tempo
HEADmaster
Nesse grafo os commits são representados por vértices e as arestas representam a relação pai-filho (nesse
exemplo, A é pai de B e B é pai de C).
Além disso temos um apontador para a cabeça (último commit) da árvore. Esse apontador é chamado por padrão
de “master”. Temos também um “apelido” (alias) para a cabeça: HEAD.
Para boa parte das operações que executaremos o que importa é para onde o HEAD está apontando.

33. A B
Tempo
mastergit log
C
HEAD
Existe um comando chamado log que imprime o histórico de commits a partir do HEAD.
Nesse exemplo teríamos: C, B, A

34. A C
Tempo
mastergit log
B
HEAD

35. A B C
Tempo
mastergit log HEAD

36. A B C
Tempo
master HEAD
Suponha agora que encontraram um bug no seu código enquanto você estava implementando uma funcionalidade.
Em muitos casos não é uma boa ideia implementar a funcionalidade e corrigir o bug ao mesmo tempo. Se algo der
errado pode ser difícil encontrar o que precisa ser desfeito.
Se estivéssemos em duas pessoas, por exemplo, uma poderia implementar a funcionalidade e a outra em
PARALELO corrigiria o bug. Assim cada um terá uma versão diferente dos arquivos.
Para criar essa “ramificação" basta usar o comando branch. Ele simplesmente cria mais um apontador, no caso
chamado “bug”.

37. A B C
Tempo
mastergit branch HEAD
Suponha agora que encontraram um bug no seu código enquanto você estava implementando uma funcionalidade.
Em muitos casos não é uma boa ideia implementar a funcionalidade e corrigir o bug ao mesmo tempo. Se algo der
errado pode ser difícil encontrar o que precisa ser desfeito.
Se estivéssemos em duas pessoas, por exemplo, uma poderia implementar a funcionalidade e a outra em
PARALELO corrigiria o bug. Assim cada um terá uma versão diferente dos arquivos.
Para criar essa “ramificação" basta usar o comando branch. Ele simplesmente cria mais um apontador, no caso
chamado “bug”.

38. A B C
Tempo
mastergit branch HEAD
bug
Suponha agora que encontraram um bug no seu código enquanto você estava implementando uma funcionalidade.
Em muitos casos não é uma boa ideia implementar a funcionalidade e corrigir o bug ao mesmo tempo. Se algo der
errado pode ser difícil encontrar o que precisa ser desfeito.
Se estivéssemos em duas pessoas, por exemplo, uma poderia implementar a funcionalidade e a outra em
PARALELO corrigiria o bug. Assim cada um terá uma versão diferente dos arquivos.
Para criar essa “ramificação" basta usar o comando branch. Ele simplesmente cria mais um apontador, no caso
chamado “bug”.

39. A B C
Tempo
git commit
bug
HEADmaster
Agora se fizermos um novo commit D, que apontador deveria ser atualizado?
Lembre-se que a nossa referência é o HEAD. Assim, o master passa a apontar para D e bug se mantém em C.

40. A B C
Tempo
git commit
bug
D
HEADmaster
Agora se fizermos um novo commit D, que apontador deveria ser atualizado?
Lembre-se que a nossa referência é o HEAD. Assim, o master passa a apontar para D e bug se mantém em C.

41. A B C
Tempo
git commit
bug
D
HEADmaster
Agora se fizermos um novo commit D, que apontador deveria ser atualizado?
Lembre-se que a nossa referência é o HEAD. Assim, o master passa a apontar para D e bug se mantém em C.

42. A B C
Tempo
git checkout
bug
D
HEADmaster
Assim, se quisermos trabalhar na branch “bug”, devemos mudar o HEAD para “bug" com o comando checkout.
Com isso os novos commits estarão na branch “bug" e não na “master".

43. A B C
Tempo
git checkout
bug
D
HEAD
master
Assim, se quisermos trabalhar na branch “bug”, devemos mudar o HEAD para “bug" com o comando checkout.
Com isso os novos commits estarão na branch “bug" e não na “master".

44. A B C
Tempo
git checkout
bug
D
HEAD
master
E
Assim, se quisermos trabalhar na branch “bug”, devemos mudar o HEAD para “bug" com o comando checkout.
Com isso os novos commits estarão na branch “bug" e não na “master".

45. A B C
Tempo
git checkout
bug
D
HEAD
master
E
Assim, se quisermos trabalhar na branch “bug”, devemos mudar o HEAD para “bug" com o comando checkout.
Com isso os novos commits estarão na branch “bug" e não na “master".

46. A B C
Tempo
git log
bug
D
HEAD
master
E
Agora se executarmos um git log devemos ver (lembre-se que a referência é o HEAD): E, C, B, A
Se fizermos um checkout para master e reexecutarmos o log teremos: D, C, B, A

47. A B C
Tempo
git log
bug
D
HEAD
master
E
Agora se executarmos um git log devemos ver (lembre-se que a referência é o HEAD): E, C, B, A
Se fizermos um checkout para master e reexecutarmos o log teremos: D, C, B, A

48. A B C
Tempo
bug
D
HEAD
E
F
H
G
master
Suponha que você terminou de corrigir o bug. Temos agora duas versões diferentes do nosso projeto. Precisamos
unificar as mudanças.
Para isso utilizamos o comando merge (note que estamos na branch master). Ele unifica as versões dos arquivos e
cria um novo commit I.
!
É possível que o mesmo arquivo possua modificações diferentes na mesma linha em ambas as branches. Nesse
caso o git não saberá como resolver o conflito e o deixará indicado.
Se isso acontecer (e vai acontecer) não se desespere. Basta manualmente abrir o arquivo, resolver o conflito e criar
um novo commit.

49. A B C
Tempo
git merge
bug
D
HEAD
E
F
H
G
master
Suponha que você terminou de corrigir o bug. Temos agora duas versões diferentes do nosso projeto. Precisamos
unificar as mudanças.
Para isso utilizamos o comando merge (note que estamos na branch master). Ele unifica as versões dos arquivos e
cria um novo commit I.
!
É possível que o mesmo arquivo possua modificações diferentes na mesma linha em ambas as branches. Nesse
caso o git não saberá como resolver o conflito e o deixará indicado.
Se isso acontecer (e vai acontecer) não se desespere. Basta manualmente abrir o arquivo, resolver o conflito e criar
um novo commit.

50. A B C
Tempo
git merge
bug
D
HEAD
E
F
H
G I
master
Suponha que você terminou de corrigir o bug. Temos agora duas versões diferentes do nosso projeto. Precisamos
unificar as mudanças.
Para isso utilizamos o comando merge (note que estamos na branch master). Ele unifica as versões dos arquivos e
cria um novo commit I.
!
É possível que o mesmo arquivo possua modificações diferentes na mesma linha em ambas as branches. Nesse
caso o git não saberá como resolver o conflito e o deixará indicado.
Se isso acontecer (e vai acontecer) não se desespere. Basta manualmente abrir o arquivo, resolver o conflito e criar
um novo commit.

51. A B C
Tempo
git merge
bug
D
HEAD
E
F
H
G I
master
Suponha que você terminou de corrigir o bug. Temos agora duas versões diferentes do nosso projeto. Precisamos
unificar as mudanças.
Para isso utilizamos o comando merge (note que estamos na branch master). Ele unifica as versões dos arquivos e
cria um novo commit I.
!
É possível que o mesmo arquivo possua modificações diferentes na mesma linha em ambas as branches. Nesse
caso o git não saberá como resolver o conflito e o deixará indicado.
Se isso acontecer (e vai acontecer) não se desespere. Basta manualmente abrir o arquivo, resolver o conflito e criar
um novo commit.

52. Repositório
Remoto
Suponha agora que seu colega de trabalho possui um repositório na máquina dele e você gostaria de colaborar no
mesmo projeto.
Lembrando que o git sempre cria uma cópia local precisamos entender como funcionam os mecanismos de
comunicação entre repositórios.

53. A B C
Tempo
HEADmaster Repositório
remoto
Repositório
local
Chamaremos de repositório na máquina de seu colega de repositório remoto. Convencionalmente se chama tal
repositório de “origin”.
Para criar uma cópia de origin em sua máquina utilizamos o comando “clone”, que cria uma cópia exata do
repositório.
Porém o apontador “master" no repositório local aponta para os commits na sua máquina, enquanto o “master" de
origin aponta para os commits naquele repositório. Assim se ocorrer alguma atualização pode ser difícil encontrar
as diferenças entre os repositórios.
Para isso existe um apontador “origin/master” que é uma referência ao master da origin.

54. A B C
Tempo
git clone
HEADmaster Repositório
remoto
Repositório
local
Chamaremos de repositório na máquina de seu colega de repositório remoto. Convencionalmente se chama tal
repositório de “origin”.
Para criar uma cópia de origin em sua máquina utilizamos o comando “clone”, que cria uma cópia exata do
repositório.
Porém o apontador “master" no repositório local aponta para os commits na sua máquina, enquanto o “master" de
origin aponta para os commits naquele repositório. Assim se ocorrer alguma atualização pode ser difícil encontrar
as diferenças entre os repositórios.
Para isso existe um apontador “origin/master” que é uma referência ao master da origin.

55. A B C
Tempo
git clone
HEADmaster Repositório
remoto
A B C
HEADmaster
Repositório
local
Chamaremos de repositório na máquina de seu colega de repositório remoto. Convencionalmente se chama tal
repositório de “origin”.
Para criar uma cópia de origin em sua máquina utilizamos o comando “clone”, que cria uma cópia exata do
repositório.
Porém o apontador “master" no repositório local aponta para os commits na sua máquina, enquanto o “master" de
origin aponta para os commits naquele repositório. Assim se ocorrer alguma atualização pode ser difícil encontrar
as diferenças entre os repositórios.
Para isso existe um apontador “origin/master” que é uma referência ao master da origin.

56. A B C
Tempo
git clone
HEADmaster Repositório
remoto
A B C
HEADmaster
Repositório
local
origin/master
Chamaremos de repositório na máquina de seu colega de repositório remoto. Convencionalmente se chama tal
repositório de “origin”.
Para criar uma cópia de origin em sua máquina utilizamos o comando “clone”, que cria uma cópia exata do
repositório.
Porém o apontador “master" no repositório local aponta para os commits na sua máquina, enquanto o “master" de
origin aponta para os commits naquele repositório. Assim se ocorrer alguma atualização pode ser difícil encontrar
as diferenças entre os repositórios.
Para isso existe um apontador “origin/master” que é uma referência ao master da origin.

57. A B C
Tempo
git clone
HEADmaster Repositório
remoto
A B C
HEADmaster
Repositório
local
origin/master
(origin)
Chamaremos de repositório na máquina de seu colega de repositório remoto. Convencionalmente se chama tal
repositório de “origin”.
Para criar uma cópia de origin em sua máquina utilizamos o comando “clone”, que cria uma cópia exata do
repositório.
Porém o apontador “master" no repositório local aponta para os commits na sua máquina, enquanto o “master" de
origin aponta para os commits naquele repositório. Assim se ocorrer alguma atualização pode ser difícil encontrar
as diferenças entre os repositórios.
Para isso existe um apontador “origin/master” que é uma referência ao master da origin.

58. A B C
Tempo
HEADmaster Repositório
remoto
A B C
HEADmaster
Repositório
local
origin/master
(origin)
D
E
Suponha que seu colega fez um commit D na máquina dele e você fez um commit E na sua máquina. O seu
repositório se encontra desatualizado. Para atualizá-lo basta executar o comando git fetch.

59. A B C
Tempo
git fetch
HEADmaster Repositório
remoto
A B C
HEADmaster
Repositório
local
origin/master
(origin)
D
E
Suponha que seu colega fez um commit D na máquina dele e você fez um commit E na sua máquina. O seu
repositório se encontra desatualizado. Para atualizá-lo basta executar o comando git fetch.

60. A B C
Tempo
git fetch
HEADmaster Repositório
remoto
A B C
HEADmaster
Repositório
local
origin/master
(origin)
D
E
D
Suponha que seu colega fez um commit D na máquina dele e você fez um commit E na sua máquina. O seu
repositório se encontra desatualizado. Para atualizá-lo basta executar o comando git fetch.

61. A B C
Tempo
git merge
HEADmaster Repositório
remoto
A B C
HEADmaster
Repositório
local
origin/master
(origin)
D
E
D
Temos duas versões (branches) distintas. Devemos então unificá-las. Para isso novamente usamos o comando
merge.

62. A B C
Tempo
git merge
HEADmaster Repositório
remoto
A B C
HEADmaster
Repositório
local
origin/master
(origin)
D
E
D
D
Temos duas versões (branches) distintas. Devemos então unificá-las. Para isso novamente usamos o comando
merge.

63. A B C
Tempo
git pull
HEADmaster Repositório
remoto
A B C
HEADmaster
Repositório
local
origin/master
(origin)
D
E
D
D
Alternativamente podemos utilizar o git pull, que faz o fetch e o merge. Consulte http://marlacorinne.
4parkers.com/2012/07/20/git-pull-vs-git-fetch-then-merge/ para uma discussão sobre pull X fetch+merge.

64. A B C
Tempo
git push
HEADmaster Repositório
remoto
A B C
HEADmaster
Repositório
local
origin/master
(origin)
D
E
D
D
Agora o origin está desatualizado. Devemos então atualizá-lo com o comando git push.

65. A B C
Tempo
git push
HEADmaster Repositório
remoto
A B C
HEADmaster
Repositório
local
origin/master
(origin)
D
E
D
D
E
D
Agora o origin está desatualizado. Devemos então atualizá-lo com o comando git push.

66. Note que não importa se a máquina do seu colega é a mesma que a sua, ou se está na mesma rede (é possível
fazer clone via ssh, por exemplo). Assim, poderia existir um servidor central com os repositórios remotos a partir
dos quais os participantes de um projeto poderiam fazer os clones locais.
É essa a ideia do github (https://github.com/), bitbucket (https://bitbucket.org/) e outros. Em ambos basta fazer um
cadastro e começar criar os repositórios. E ambos possuem versões gratuitas (no Github só é possível ter
repositórios de código aberto em uma conta gratuita) com limitações de número de colaboradores e tamanho do
projeto e pagas.

67. CONCLUSÃOCONCLUSÃO
Para finalizar apresentaremos algumas dicas de onde ir e o que estudar a partir desse ponto.

68. Dicas
1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do
último slide);
2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens
expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;
3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/
Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos
arquivos, mas é (bastante) possível que ocorra algo imprevisível.
4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só
operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no
entendimento do histórico posteriormente e facilitam na hora de fazer um merge.
5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

69. 1. git rebase
Dicas
1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do
último slide);
2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens
expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;
3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/
Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos
arquivos, mas é (bastante) possível que ocorra algo imprevisível.
4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só
operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no
entendimento do histórico posteriormente e facilitam na hora de fazer um merge.
5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

70. 1. git rebase
2. mensagens de commit
Dicas
1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do
último slide);
2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens
expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;
3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/
Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos
arquivos, mas é (bastante) possível que ocorra algo imprevisível.
4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só
operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no
entendimento do histórico posteriormente e facilitam na hora de fazer um merge.
5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

71. 1. git rebase
2. mensagens de commit
3. commit antes de mudança
Dicas
1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do
último slide);
2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens
expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;
3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/
Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos
arquivos, mas é (bastante) possível que ocorra algo imprevisível.
4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só
operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no
entendimento do histórico posteriormente e facilitam na hora de fazer um merge.
5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

72. 1. git rebase
2. mensagens de commit
3. commit antes de mudança
4. commit sempre
Dicas
1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do
último slide);
2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens
expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;
3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/
Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos
arquivos, mas é (bastante) possível que ocorra algo imprevisível.
4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só
operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no
entendimento do histórico posteriormente e facilitam na hora de fazer um merge.
5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

73. 1. git rebase
2. mensagens de commit
3. commit antes de mudança
4. commit sempre
5. master com versão funcional
Dicas
1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do
último slide);
2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens
expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;
3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/
Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos
arquivos, mas é (bastante) possível que ocorra algo imprevisível.
4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só
operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no
entendimento do histórico posteriormente e facilitam na hora de fazer um merge.
5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

74. Revisando…
Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.

75. + init: cria .git
Revisando…
Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.

76. + init: cria .git
+ add: adiciona no índice
Revisando…
Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.

77. + init: cria .git
+ add: adiciona no índice
+ commit: cria commit
Revisando…
Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.

78. + init: cria .git
+ add: adiciona no índice
+ commit: cria commit
+ branch: cria branch
Revisando…
Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.

79. + init: cria .git
+ add: adiciona no índice
+ commit: cria commit
+ branch: cria branch
+ merge: une branches
Revisando…
Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.

80. + init: cria .git
+ add: adiciona no índice
+ commit: cria commit
+ branch: cria branch
+ merge: une branches
+ pull/push: recebe/envia para o remoto
Revisando…
Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.

81. Links
Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam
outros conteúdos que não estão presentes nessa apresentação.
Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os
principais comandos a serem utilizados no dia a dia.
Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes.
O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git.
O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.

82. + Entendendo o git conceitualmente: http://www.sbf5.com/
~cduan/technical/git/
Links
Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam
outros conteúdos que não estão presentes nessa apresentação.
Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os
principais comandos a serem utilizados no dia a dia.
Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes.
O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git.
O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.

83. + Entendendo o git conceitualmente: http://www.sbf5.com/
~cduan/technical/git/
+ git (DAG): http://eagain.net/articles/git-for-computer-scientists/
Links
Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam
outros conteúdos que não estão presentes nessa apresentação.
Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os
principais comandos a serem utilizados no dia a dia.
Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes.
O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git.
O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.

84. + Entendendo o git conceitualmente: http://www.sbf5.com/
~cduan/technical/git/
+ git (DAG): http://eagain.net/articles/git-for-computer-scientists/
+ Tutorial interativo: https://try.github.io
Links
Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam
outros conteúdos que não estão presentes nessa apresentação.
Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os
principais comandos a serem utilizados no dia a dia.
Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes.
O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git.
O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.

85. + Entendendo o git conceitualmente: http://www.sbf5.com/
~cduan/technical/git/
+ git (DAG): http://eagain.net/articles/git-for-computer-scientists/
+ Tutorial interativo: https://try.github.io
+ Tutorial "oficial": http://git-scm.com/docs/gittutorial
Links
Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam
outros conteúdos que não estão presentes nessa apresentação.
Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os
principais comandos a serem utilizados no dia a dia.
Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes.
O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git.
O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.

86. + Entendendo o git conceitualmente: http://www.sbf5.com/
~cduan/technical/git/
+ git (DAG): http://eagain.net/articles/git-for-computer-scientists/
+ Tutorial interativo: https://try.github.io
+ Tutorial "oficial": http://git-scm.com/docs/gittutorial
+ Fluxos de trabalho: https://www.atlassian.com/git/workflows
Links
Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam
outros conteúdos que não estão presentes nessa apresentação.
Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os
principais comandos a serem utilizados no dia a dia.
Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes.
O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git.
O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.

87. + Entendendo o git conceitualmente: http://www.sbf5.com/
~cduan/technical/git/
+ git (DAG): http://eagain.net/articles/git-for-computer-scientists/
+ Tutorial interativo: https://try.github.io
+ Tutorial "oficial": http://git-scm.com/docs/gittutorial
+ Fluxos de trabalho: https://www.atlassian.com/git/workflows
+ Mostrando branch: http://www.vidageek.net/2009/07/20/
como-exibir-branch-atual-do-git/
Links
Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam
outros conteúdos que não estão presentes nessa apresentação.
Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os
principais comandos a serem utilizados no dia a dia.
Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes.
O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git.
O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.