O documento apresenta uma introdução ao controle de versão com Git, discutindo sua necessidade, evolução, instalação e fluxo de trabalho básico, incluindo a hospedagem de repositórios remotos.

1. CONTROLE DE VERSÃO COM
GIT
Vanessa Me Tonini - 28.08.19

2. TODAY'S
PRESENTATION
DISCUSSION POINTS
Controle de versão e sua necessidade
O que é um sistema de controle de versão (SCV)
Evolução dos SCV
Breve Histórico
Instalação
Fluxo de trabalho (flows)
Times distribuídos
Fazendo modificações
Hospedagem de repositórios
Enviando e recebendo modificações
Estudos pro futuro
C o n t r o l e d e v e r s ã o c o m G i t | V a n e s s a T o n i n i

3. C o n t r o l e d e v e r s ã o c o m G i t | V a n e s s a T o n i n i
VANESSA ME TONINI
INSTRUTORA E DESENVOLVEDORA
NA CAELUM
E X P E R I E N C E
C O N T R I B U T I O N S
Trabalha com desenvolvimento web há mais de 10 anos.
Aluna do mestrado em Ciência da Computação no IME - USP.
Coordenadora do coletivo hacker feminista Marialab.
Vegetariana e praticante de meditação. ☮☯

4. O QUE É CONTROLE DE
VERSÃO?
E Q U A L N E C E S S I D A D E D I S S O ?

5. Controle de versão - PQ?
T R A B A L H O E M T I M E
Distribuir cópias do projeto para
que cada membro possa trabalhar
em sua parte
H I S T Ó R I C O D E
M O D I F I C A Ç Õ E S
Registro detalhado das
modificações realizadas nos
arquivos do projeto
C O N S U L T A
Buscar no histórico de
modificações em pontos
específicos, para recuperar
arquivos

6. O QUE É UM SISTEMA DE
CONTROLE DE VERSÃO?

7. É uma categoria de software que automatiza as
tarefas de controle versão. Como o registro de
modificações de arquivos ao longo do tempo
através do uso de uma base de dados especial.
E comparação e recuperação de versões
anteriores etc.

8. EVOLUÇÃO DOS SCV
1 9 7 0 S C C S
Unix Bell Labs
1 9 8 0 R C S
Unix & GNU
1 9 8 5 C V S
Academic purpose for
ACK
2 0 0 0 S V N
Subversion by CollabNet
2 0 0 5 G I T
Linus for Linux

9. F o t o : D i v u l g a ç ã o D i o L i n u x
BREVE HISTÓRICO
ADAPTING TO CHANGES
O kernel (núcleo) do Linux é um projeto de software de código
aberto de grande escopo. Durante a maior parte do período de
manutenção do kernel do Linux (1991-2002), as mudanças no
software eram repassadas como patches e arquivos
compactados. Em 2002, o projeto do kernel do Linux começou
a usar um sistema DVCS proprietário chamado BitKeeper.
Em 2005, o relacionamento entre a comunidade que
desenvolvia o kernel e a empresa que desenvolvia
comercialmente o BitKeeper se desfez, e o status de isento-de-
pagamento da ferramenta foi revogado
Isso levou a comunidade de desenvolvedores do Linux (em
particular Linus Torvalds, o criador do Linux) a desenvolver sua
própria ferramenta baseada nas lições que eles aprenderam ao
usar o BitKeeper.
Desde sua concepção em 2005, o Git evoluiu e amadureceu a
ponto de ser um sistema fácil de usar e ainda assim mantém
essas qualidades iniciais. É incrivelmente rápido, bastante
eficiente com grandes projetos e possui um sistema
impressionante de branching para desenvolvimento não-linear.

10. O QUE A
COMUNIDADE
LINUX
QUERIA PARA
O NOVO
SISTEMA DE
CONTROLE
VERSÃO?
FACTORS FOR SUCCESS
Velocidade
Design simples
Suporte robusto a
desenvolvimento não linear
Eficiência com projetos grande

12. C o n t r o l e d e v e r s ã o c o m G i t | V a n e s s a T o n i n i
TRENDS 2004 ATÉ O PRESENTE

13. C o n t r o l e d e v e r s ã o c o m G i t | V a n e s s a T o n i n i
SURVEY
2018
h t t p s : / / i n s i g h t s . s t a c k o v e r f l o w . c o m / s u r v e y / 2 0 1 8 / # d e v e l o p m e n t - p r a c t i c e s

14. GET STARTED!
V A M O S C O M E Ç A R !

15. C o n t r o l e d e v e r s ã o c o m G i t | V a n e s s a T o n i n ih t t p s : / / x k c d . c o m / 1 5 9 7 /
- Este é o Git. Ele rastreia o trabalho
colaborativo em projetos através de um
belo distribuído modelo de árvore da
teoria dos grafos.
- Legal. Como usamos isso?
- Nenhuma idéia. Apenas memorize esses
comandos de shell e digite-os para
sincronizar. Se você receber erros, salve
seu trabalho em outro lugar, exclua o
projeto e baixe uma nova cópia.

16. C o n t r o l e d e v e r s ã o c o m G i t | V a n e s s a T o n i n ih t t p s : / / x k c d . c o m / 1 5 9 7 /
- Este é o Git. Ele rastreia o trabalho
colaborativo em projetos através de um
belo distribuído modelo de árvore da
teoria dos grafos.
- Legal. Como usamos isso?
- Nenhuma idéia. Apenas memorize esses
comandos de shell e digite-os para
sincronizar. Se você receber erros, salve
seu trabalho em outro lugar, exclua o
projeto e baixe uma nova cópia.

17. INSTALAÇÃO
https://git-scm.com
Com isto o comando
git
será disponibilizado no
terminal de linha de
comando do seu
computador

18. COMO O GIT FUNCIONA?
B A S E I A - S E E M T R Ê S E S T A D O S P A R A O S A R Q U I V O S
Q U A S E T O D A S A S O P E R A Ç Õ E S S Ã O L O C A I S
G R A V A " S N A P S H O T S " E N Ã O A S D I F E R E N Ç A S
comprometido (commited), modificados (modified) e preparados (staged).
Só precisa de internet se for enviar suas modificações para outro computador.
Você grava uma espécie de "fotografia" do estado dos seus arquivos,
caracterizando cada "fotografia" um ponto de modificações em uma linha do
tempo.

19. CONFIGURAÇÕES GLOBAIS
U S U Á R I O E E M A I L
As configurações obrigatórias que devem ser feitas antes de usar o
sistema de controle de versão do git são: informar um nome de usuário e
um email.
Sem isto não será possível comprometer os arquivos, ou seja, versionar
eles. Pois estas informações são adicionadas quando uma "fotografia" é
feita no histórico de modificações.
Estas configurações são feitas apenas 1x, e por computador.

20. ~: git config --global user.name
"Vanessa Me Tonini"

21. ~: git config --global user.email
"vanessametonini@gmail.com"

22. ~: git config --list
user.email=vanessametonini@gmail.com
user.name=Vanessa Me Tonini

23. Após as configurações.
Criar uma pasta para seu
projeto:
FLUXO DE TRABALHO LOCAL

24. ~: mkdir semComp
~: cd semComp
~/semComp:

25. ~: mkdir semComp
~: cd semComp
~/semComp:

26. Diretório de
trabalho
Working directory

27. ~/semComp: git init

28. ~/semComp: git init
Initialized empty Git repository in /Users/Vanessa/semComp/.git/

29. Working directory
diretório .git
(repositório)
.git directory (repository)
semComp

30. é um diretório oculto, onde
jamais devemos mexer nele
(manualmente)!
.git

31. Área de
preparação
Working directory Staging area
diretório .git
(repositório)
.git directory (repository)
semComp

32. é uma área lógica (virtual)
disponibilizada
automaticamente pelo git para
adicionar os arquivos se serão
comprometidos (commited)
STAGING AREA / ÁREA DE PREPARAÇÃO

33. Área de
preparação
Working directory Staging area
diretório .git
(repositório)
.git directory (repository)
adicionei arquivos
semComp

34. ~/semComp: git status

35. ~/semComp: git status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
index.html
nothing added to commit but untracked files present (use "git add" to track)

36. Para adicionar arquivos no
versionamento, precisamos
adicioná-los no stage e depois
fazer o commit
PREPARANDO OS ARQUIVOS

37. ~/semComp: git add index.html
~/semComp: git add .

38. ~/semComp: git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: index.html

39. Área de
preparação
Working directory Staging area
diretório .git
(repositório)
.git directory (repository)
Prepara os arquivos
semComp

40. Agora vamos comprometer os
arquivos. Ou seja, todos os arquivos
que estiverem no stage vão ser
"fotografados" e entrar no histórico
de modificações do projeto. Para
isto usamos o commit.
VERSIONANDO ARQUIVOS

41. ~/semComp: git commit -m
"Adicionado homepage"
[master (root-commit) 427eade] Adicionado homepage
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 index.html

42. Área de
preparação
Working directory Staging area
diretório .git
(repositório)
.git directory (repository)
Compromete os
arquivos
semComp

43. Área de
preparação
Working directory Staging area
diretório .git
(repositório)
.git directory (repository)
semComp

44. ~/semComp: git log
commit 427eadeab40849d7a13cb2e20276cb83bfbf9c33
(HEAD -> master)
Author: Vanessa Me Tonini
<vanessametonini@gmail.com>
Date: Tue Aug 27 13:56:23 2019 -0300
Adicionado homepage

45. AGORA
T E M M A I S D O I S
C O L E G U I N H A S Q U E
P R E C I S A M T R A B A L H A R
N O P R O J E T O .
C O M O F A Z ?

46. AGORA
T E M M A I S D O I S
C O L E G U I N H A S Q U E
P R E C I S A M T R A B A L H A R
N O P R O J E T O .
C O M O F A Z ?

47. HOSPEDAGENS DE
REPOSITÓRIOS GIT
A maneira mais comum de deixar seus repositórios
compartilháveis é hospedando eles em um
servidor. Os serviços de hospedagem de
repositórios Git mais populares hoje são Gitlab,
Github e Bitbucket. Além da hospedagem, que nos
dá um endereço público na internet, estes serviços
oferecem também outras ferramentas como como
um issue tracker (gerenciador de problemas),
quadros kanban etc. Ainda alguns fazem uma
rede social (Github e Gitlab).

48. Vamos enviar o repositório local para
um repositório remoto.
FLUXO DE TRABALHO COM UMA
HOSPEDAGEM

54. AGORA TEMOS 2 REPOSITÓRIOS DISTINTOS.
1 NO MEU PC
servidor local

55. AGORA TEMOS 2 REPOSITÓRIOS DISTINTOS.
1 NO MEU PC 1 NO GITHUB
servidor remotoservidor local

56. PRECISAMOS ELES SE TORNAREM O "MESMO
REPOSITÓRIO" (OU TER A MESMA ORIGEM)
1 NO MEU PC 1 NO GITHUB
servidor remotoservidor local

61. ATENÇÃO AO ENDEREÇO DO
REPOSITÓRIO REMOTO.
POIS ISTO INFLUENCIARÁ A FORMA DE AUTENTICAÇÃO
DO COMPUTADOR LOCAL NO SERVIDOR REMOTO.
HTTPS
SSH

62. h t t p s : / / h e l p . g i t h u b . c o m / e n / e n t e r p r i s e / 2 . 1
6 / u s e r / a r t i c l e s / g e n e r a t i n g - a - n e w - s s h -
k e y - a n d - a d d i n g - i t - t o - t h e - s s h - a g e n t
C a s o v o c ê q u e i r a c a d a s t r a r s e u
c o m p u t a d o r c o m o u m p c
a u t o r i z a d o a m a n i p u l a r
l i v r e m e n t e s e u s r e p o s i t ó r i o s d o
G i t h u b , e n t ã o c r i e u m a c h a v e
S S H .
C a s o e s c o l h e r H T T P S , t o d a v e z
s e r á s o l i c i t a d o s e u u s e r n a m e e
s e n h a d o G i t h u b q u a n d o p r e c i s a r
e n v i a r o u p e g a r i n f o r m a ç õ e s d e
l á .

63. ~/semComp:
git remote add origin
https://github.com/vanessametonini/semComp.git

64. ~/semComp: git remote -v
origin https://github.com/vanessametonini/semComp.git (fetch)
origin https://github.com/vanessametonini/semComp.git (push)

66. ~/semComp: git push -u origin master
Username for 'https://github.com': vanessametonini
Password for 'https://vanessametonini@github.com':

67. ~/semComp: git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 226 bytes | 226.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:vanessametonini/semComp.git
* [new branch] master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

69. git push
Envia os dados
do atual
repositório para
um repositório
remoto.

70. git push
origin
origin é uma
variável que
guarda do
endereço do
repositório remoto

71. git push
origin
master
master é branch
(ramificação) ou
"linha do tempo"
que você quer enviar
os commits.

73. COMO FAZ
PARA ALGUÉM
(OU EU) FAZER
UMA CÓPIA DE
UM PROJETO
COM GIT?

76. ~/semComp: cd Sites/usp
~/usp:

77. ~/usp: git clone
git@github.com:vanessametonini/se
mComp.git
Cloning into 'semComp'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

78. ~/usp: git clone
git@github.com:vanessametonini/se
mComp.git
Cloning into 'semComp'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
Quando você clona
um projeto:
O git cria uma pasta com o
nome do repositório;✅
O git já adiciona a remote
origin;✅

79. Como receber as contribuições feitas
por outras pessoas? Como atualizar
meu projeto com estas contribuições?
POR ÚLTIMO:

84. ~/semComp: git pull origin master
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:vanessametonini/semComp
* branch master -> FETCH_HEAD
427eade..c096120 master -> origin/master
Updating 427eade..c096120
Fast-forward
README.md | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 README.md

85. ~/semComp: git pull origin master
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:vanessametonini/semComp
* branch master -> FETCH_HEAD
427eade..c096120 master -> origin/master
Updating 427eade..c096120
Fast-forward
README.md | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 README.md

86. O QUE SEGUIR ESTUDANDO?
RECOMMENDATIONS
Uma branch é uma
ramificação construída a
partir de outra. Todo
repositório começa com uma
única branch chamada
master. E a partir da master
podemos criar outras
branches, que são cópias da
master. Proporcionando o
desenvolvimento não linear.
B R A N C H E S
Podemos definir um fluxo de
trabalho com git. Isto é
necessário quando existe
mais pessoas trabalhando em
cima dos mesmos arquivos.
Então é importante conhecer
e acordar como serão
adicionadas novas coisas no
repositório, como por
exemplo, usar o issue tracker
do github ou gitlab.
F L U X O S
Muitas vezes, quando
recebemos atualizações do
projeto através do pull,
acontecem conflitos. O
conflito acontece quando no
seu repositório local e no
remoto, as mesmas linhas de
um arquivo são alteradas.
Então resolver você deverá
resolver os conflitos de
merge.
M E R G E

87. DÚVIDAS?
OBRIGADA!
@vanessametonini
vanessa.tonini@caelum.com.br
R E D E S