07/10/2020

FC-SLI-2020-2
Gerenciamento de código com Git e GitHub

Para que pode servir?

• Especialmente tudo que tem relação com
arquivos texto.
▫ Código-fonte
▫ Documentação
▫ Etc.

1
 07/10/2020

Sistema de Controle de Versão

• Sistema que registra as mudanças feitas em um
arquivo ou um conjunto de arquivos ao longo do
tempo de forma que você possa recuperar
versões específicas.
• Permite:
▫ Reverter arquivos ou mesmo um projeto inteiro
para um estado anterior.
▫ Comparar mudanças feitas ao decorrer do tempo.
▫ Ver quem foi o último a modificar algo que pode
estar causando problemas, quem introduziu um
bug, etc.
3

Evolução
• Sistemas de Controle de Versão Locais
▫ Exemplo: rcs
mantém conjuntos de patches (diferenças entre os
arquivos) entre cada mudança em um formato
especial.
A partir daí qualquer arquivo em qualquer ponto na
linha do tempo pode ser recriado ao juntar-se todos
os patches.

2
 07/10/2020

Evolução
• Sistemas de Controle de Versão Locais

Evolução
• Sistemas de Controle de Versão Centralizados
▫ Exemplos: CVS, Subversion e Perforce
Possuem um único servidor central que contém
todos os arquivos versionados e vários clientes que
podem resgatar (check out) os arquivos do servidor.
Todos podem ter conhecimento razoável sobre o que
os outros desenvolvedores estão fazendo no projeto.
 O servidor central é um ponto único defalha.

3
 07/10/2020

Evolução
• Sistemas de Controle de Versão Centralizados

Evolução
• Sistemas de Controle de Versão Distribuídos
▫ Exemplos: Git, Mercurial, Bazaar e Darcs
Os clientes não apenas fazem cópias das últimas versões
dos arquivos: eles são cópias completas do repositório.
Se um servidor falha, qualquer um dos repositórios dos
clientes pode ser copiado de volta para o servidor para
restaurá-lo.
Cada checkout (resgate) é na prática um backup completo
de todos os dados.
Muitos desses sistemas lidam muito bem com o aspecto
de ter vários repositórios remotos com os quais eles
podem colaborar.
Permite que você estabeleça diferentes tipos de fluxos de
trabalho que não são possíveis em sistemas centralizados.
8

4
 07/10/2020

Evolução
• Sistemas de Controle de Versão Distribuídos

Git
• Concebido em 2005 por Linus Torvalds para
gerenciar o código do Linux.
• Incrivelmente rápido.
• Tem todo o histórico do projeto no seu disco local.
▫ A maior parte das operações parece ser quase
instantânea.
• Quase todas operações são locais
▫ Há poucas coisas que você não possa fazer caso esteja
offline.
• Git tem integridade
▫ Arquivos com checksum SHA-1.

10

5
 07/10/2020

Git
• Implementação rápida e moderna de controle de
versão
• Fornece um histórico de alterações de conteúdo.
• Facilita alterações colaborativas em arquivos.
• Relativamente fácil de usar.

11

Git

12

6
 07/10/2020

Git é rápido!!!

13

Git é eficiente!!!

14

7
 07/10/2020

Git é leve!!!

15

Git é muito usado

16

8
 07/10/2020

Permite qualquer fluxo de trabalho

17

Git Local
• Distribuído de modo que a falta de conectividade
não afeta o trabalho
• Aprendizado dos seus comandos pode ocorrer
progressivamente.

18

9
 07/10/2020

Git distribuído
• Voltado para trabalho em equipe, de modo que a
colaboração ocorre naturalmente.

19

20

10
 07/10/2020

21

Instalação
• Linux (Ubuntu)
▫ sudo apt-get install git-core gitk tig

• Windows
▫ Baixar e instalar a versão mais recente

• Mac OS
▫ Baixar e instalar a versão mais recente

22

11
 07/10/2020

23

24

12
 07/10/2020

Snapshots e não Diferenças

Git armazena dados como snapshots do projeto ao longo do tempo

25

Os três estados
• Arquivos sempre estão em um dos três estados
fundamentais:
▫ modificado (modified)
arquivo que sofreu mudanças, mas que ainda não foi
consolidado na base de dados.
▫ preparado (staged)
quando você marca um arquivo modificado em sua
versão corrente para que ele faça parte do snapshot
do próximo commit (consolidação).
▫ consolidado (committed)
Dados seguramente armazenados em sua base de
dados local.
26

13
 07/10/2020

Repositório local
• Consiste em três "árvores" mantidas pelo git:
▫ Working Directory
 Contém os arquivos vigentes.
▫ Index
 Funciona como uma área temporária
▫ HEAD
 Aponta para o último commit (confirmação) que você fez
 É uma referência para o último commit do branch atual

27

Área de preparação

28

14
 07/10/2020

Criar um novo repositório

• git init

29

Criar um novo repositório a partir

de um repositório já existente
• Cópia de trabalho de um repositório local para outro repositório
local
▫ git clone /caminho/para/o/repositório
• Cópia de trabalho de um repositório remoto para um repositório
local
▫ git clone usuário@servidor:/caminho/para/o/repositório
▫ Exemplo:
git clone https://usuario@github.com/wlagithub/fc-sli-2020-2.git

▫ Se o usuário não for definido durante o clone, ele será requisitado sempre que
for feita alguma operação remota que exija autenticação.

30

15
 07/10/2020

GitHub
• Março/2012
▫ ~1,5 milhão de usuários
▫ ~2,5 milhões de repositórios

31

Conectando um repositório local a

um repositório remoto
• Caso o repositório local não tenha sido criado a
partir de um clone:
▫ git remote add origin <servidor>

32

16
 07/10/2020

Alterando os dados de um
repositório remoto já configurado
• git remote set-url origin https://
usuario@github.com/wlagithub/fc-sli-2020-2.git

33

34

17
 07/10/2020

Adicionar e confirmar
• Você pode propor mudanças (adicioná-las
ao Index) usando:
▫ git add <arquivo>
▫ git add .
▫ git add *

• Para confirmar (commit) estas mudanças, use:

▫ git commit -m "comentários das
alterações"
▫ Agora o arquivo é enviado para o HEAD, mas
ainda não para o repositório remoto.
35

Enviando alterações
• Alterações agora estão no HEAD da cópia de
trabalho local.
• Para enviá-las ao repositório remoto:
▫ git push origin master
 Repositório remoto:origin
Branch local: master

36

18
 07/10/2020

Ramificações - Branches
• Usados para desenvolver funcionalidades isoladas
umas das outras.
• Branch master – branch padrão ao criar um
repositório.
• Use branches durante o desenvolvimento e depois,
mescle-os (merge) ao master.

37

Ramificações - Branches
• Branch é uma ramificação no desenvolvimento.
• Uma técnica utilizada é fazer um branch para cada
funcionalidade implementada
• Criar e selecionar um novo branch
▫ git checkout -b funcionalidade_x
• Retornar ao branch master
▫ git checkout master
• Remover o branch
▫ git branch -d funcionalidade_x
• Enviando o novo branch ao repositório remoto
▫ git push origin funcionalidade_x

38

19
 07/10/2020

Ramificações - Branches

39

Ramificações - Branches

40

20
 07/10/2020

Ramificações - Branches

41

Atualizar o repositório local

• Obter e mesclar (merge) alterações remotas
▫ git pull
 Faz um "git fetch" seguido de um "git merge"
• Mesclar (merge) de outro branch ao branch ativo
▫ git merge <branch>

42

21
 07/10/2020

Resolvendo conflitos
• Nem sempre é possível fazer o merge, pois
podem existir conflitos.
• Em caso de conflitos, é preciso editar
manualmente os arquivos.
• Após a edição, é preciso marcar os arquivos
como merged
▫ git add <arquivo>
• Para resolução de conflitos pode-se usar a
ferramenta diffmerge:
▫ http://prateekvjoshi.com/2013/06/30/how-to-
use-diffmerge/
43

Visualizando diferenças entre

branches
• git diff <branch origem> <branch destino>
• Bastante útil antes do merge.
• Exemplo:
▫ git diff master origin/master
• Outras diferenças
▫ git diff
 Diferenças entre cópia de trabalho e index
▫ git diff --cached
 Diferenças entre index eHEAD
▫ git diff HEAD
 Diferenças entre cópia de trabalho e HEAD
44

22
 07/10/2020

Rótulos - Tags
• Recomenda-se criar rótulos para releases de
software.
• Criar novo rótulo que referencia o id de commit
▫ git tag 1.0.0 1b2e1d63ff
• 1b2e1d63ff representa os 10 primeiros
caracteres do id de commit que é referenciado
com o rótulo.
• O id de commit deve ser único.
• Para obter o id de commit:
▫ git log
45

Sobrescrever alterações locais

• Usado em caso de alterações locais indevidas
• Substituir alterações na árvore de trabalho pelo
conteúdo mais recente do HEAD.
▫ git checkout <arquivo>
• Alterações já adicionadas ao index e novos
arquivos são mantidos.

46

23
 07/10/2020

Sobrescrever alterações locais

• Para remover todas as alterações e commits
locais:
▫ git fetch origin
▫ git reset --hard origin/master

47

Uso básico (simplificado)

48

24
 07/10/2020

Uso básico (simplificado)

• git add files
▫ Copia arquivos em seu estado atual para o stage (área temporária
/ index).
• git commit
▫ Salve um snapshot (instantâneo) do stage como um commit.
• git reset -- files
▫ unstages files, ou seja: copia arquivos do último commit para o stage.
▫ Usado para desfazer um git add files.
▫ Pode-se usar git reset para fazer unstage de tudo.
▫ Atualiza o index, movendo HEAD.
• git checkout -- files
▫ Copia arquivos do stage para o diretório de trabalho.
▫ Descarta as alterações locais.
▫ Atualiza o diretório de trabalho.

49

Evitando o envio de alguns arquivos

• .gitignore
▫ Um arquivo .gitignore pode ser criado para evitar
o envio indesejado de alguns arquivos específicos
para o repositório.
target/*
.settings/*
.classpath
.project
/target
*.class
*.jar
*.war
*.ear
50

25
 07/10/2020

Evitando envios de modificações

• É possível evitar o envio de determinadas
modificações
• git update-index --assume-unchanged nome_arquivo.ext

51

Dicas
• Inteface gráfica padrão
▫ gitk
• Usar saídas do git coloridas
▫ git config color.ui true
• Exibir log em apenas uma linha por commit
▫ git config format.pretty oneline
• Fazer inclusões interativas
▫ git add –i
• Ferramenta de diff
▫ diffmerge
 http://www.andrejkoelewijn.com/wp/2010/01/08/configure-diffmerge-with-git/
 http://adventuresincoding.com/2010/04/how-to-setup-git-to-use-diffmerge
52

26
 07/10/2020

Dicas
• tig
▫ Excelente interface texto para o Git.

53

Fluxo de trabalho - Workflow

• Quando trabalhamos com Git não faz sentido
pensarmos em comandos isolados, mas em um
fluxo de trabalho.

54

27
 07/10/2020

Exemplo de Workflow

55

Fluxo de trabalho para enviar e receber

alterações
• branch work
▫ Recebe todas as alterações locais.
▫ Alterações locais serão realizadas nesse branch e não no
master.
▫ Facilita o gerenciamento de conflitos.
▫ Criando esse branch:
 git checkout -b work
• branch master
▫ realiza as comunicações remotas para receber e enviar
alterações.
▫ Recomenda-se que toda a comunicação com repositórios
externos seja feita através dele, já que está sempre “limpo”
56

28
 07/10/2020

Fluxo de trabalho para enviar e receber

alterações
# mudando para o branch
work git checkout work
# Adicionando arquivos do diretório corrente
e # seus subdiretórios ao índice
git add .
# Salvando todas as mudanças no repositório local
git commit --am "mensagem personalizada referente
às alterações realizadas"
# mudando para o branch
master git checkout master

57

Fluxo de trabalho para enviar e receber

alterações
# trazendo alterações externas para o
repositório # local (branch master)
git pull
# mudando para o branch work
git checkout work
# Atualizar o work com as alterações externas
# que estão no master
git rebase master

58

29
 07/10/2020

Fluxo de trabalho para enviar e

receber alterações
• Explicando melhor
▫ git rebase master
 Atualiza o work com as alterações externas que estão no
master (rebase).
 Mantém o work atualizado e com uma quantidade menor
de conflitos em relação ao master.
 O rebase analisa commit a commit.
 Pega todo o histórico de commits e analisa um a um, do
primeiro ao último.
 Reduz a quantidade de conflitos a serem resolvidos de uma
única vez ao final do desenvolvimento
 Em caso de conflitos...
 git mergetool
 git rebase --continue
59

Fluxo de trabalho para enviar e

receber alterações
# mudando para o branch master
git checkout master

# trazendo as alterações do work para o

master git merge work

# Enviando alterações efetuadas

("comitadas") no repositório local (master)
# para o repositório remoto
git push

60

30
 07/10/2020

git add
• git add --A
▫ Todos os arquivos novos, alterados e removidos
para stage
• git add .
▫ Arquivos novos e alterados, mas não os removidos
para stage.
• git add –u
▫ Arquivos modificados e removidos, mas não novos
para stage.

61

git commit -a
• Significa quase o mesmo que:
▫ git add --u && git commit
▫ A diferença é sutil e só existe se não estiver na raiz
do repositório.

62

31
 07/10/2020

git reset
• --soft
▫ Move para onde está o HEAD
• sem opção
▫ Faz o anterior e faz com que o Index fique como o
HEAD
• --hard
▫ Faz o anterior e faz com que o diretório de
trabalho fique como o Index.

63

Criando e usando um repositório privado

remoto
No servidor:
1 - Instalar o git:
sudo apt-get install git-core

2 - Entrar no diretório do usuário e:

mkdir meu_projeto.git
cd meu_projeto.git
git init --bare

64

32
 07/10/2020

Criando e usando um repositório privado

remoto
No cliente:
git clone
usuario@host:meu_projeto.git cd
meu_projeto
touch README
git add .
git commit -m "Initial commit"
git push origin
master git pull

Usando SSH com porta não default no servidor (Exemplo: porta 1720):
git clone
ssh://usuario@host:1720/~/meu_projeto.git 65

Repositório Bare
• Contém as informações de controle de versão,
mas não tem diretório de trabalho, nem o sub-
diretório .git.
▫ Todo o contéudo que estaria dentro do sub-
diretório .git fica direto na raiz da aplicação.
• O repositório precisa ser bare (sem arquivos de
trabalho) para poder aceitar um push.
• Push só é possível em repositórios “bare” (sem
arquivos de trabalho)

66

33
 07/10/2020

Referências
• Site e documentação oficial
▫ http://git-scm.com/
▫ http://git-scm.com/documentation
• git - guia prático: apenas um guia prático para
começar com git. sem complicação ;)
▫ http://rogerdudler.github.io/git-guide/
index.pt_BR.html
• Pro Git book
▫ http://git-scm.com/book/pt-br/
• Git Cheatsheets
▫ http://ndpsoftware.com/git-cheatsheet.html
▫ https://na1.salesforce.com/help/pdfs/en/
salesforce_git_developer_cheatsheet.pdf 67

Referências
• Apresentações sobre Git
▫ http://tableless.com.br/slides-devs-10-git/
• Excelente tutorial sobre Git!!!
▫ https://www.atlassian.com/git/

68

34