git

conteúdo

1. Introdução
2. Noções Básicas do Git
3. Efetivando Mudanças
4. Etiquetagem
5. Revertendo Mudanças
6. Repositórios Remotos

1
 Git
Introdução

O QUE É GIT?

• Git é um sistema de controle de

versões distribuído;

• Usado principalmente no
desenvolvimento de software;

2
 O QUE É GIT?

• O Git pode ser usado para registrar o

histórico de edições de qualquer tipo de
arquivo;

• Exemplo: alguns livros digitais são

disponibilizados no GitHub e escrito aos
poucos publicamente

UMA BREVE HISTÓRIA DO GIT

• O kernel Linux é um projeto de software

de código aberto de escopo bastante
amplo.

• Durante os primeiros anos da

manutenção do kernel Linux (1991–2002),

• As alterações no software eram feitas

através de arquivos e patches arquivados.

3
 UMA BREVE HISTÓRIA DO GIT

Em 2002, o projeto do kernel Linux

começou a usar um Sistema de Controle
de Versão Distribuído proprietário na
época chamado BitKeeper.

UMA BREVE HISTÓRIA DO GIT

• Em 2005, a relação entre a comunidade

Linux e a empresa desenvolvedora do
BitKeeper se encerrou;

• E o status gratuito da ferramenta foi

revogada.

4
 UMA BREVE HISTÓRIA DO GIT

• Linus Torvalds, criador do Linux, e a

comunidade decidiram criar sua própria
ferramenta de controle de versão;

• Baseados nas lições aprendidas ao

usarem o BitKeeper.

• Lançamento do Git: 7 de abril de 2005

OBJETIVOS DO GIT
• Velocidade;

• Design simples;

• Suporte forte para desenvolvimento não-

linear (múltiplos ramos em paralelo);

• Totalmente distribuído;

• Capaz de lidar com grandes projetos

como o kernel do Linux.

10

10

5
 GIT
• Desde 2005, o Git evoluiu para ser fácil
de usar;

• Mantendo as qualidades iniciais: rapidez,

eficiência em grandes projetos, com o
Linux;

• E, com um sistema de ramificação

poderoso para desenvolvimento não-
linear.

11

11

FORMA DE ARMAZENAR DADOS

• A principal diferença entre o Git e

qualquer outro Sistemas de Controle
de Versão;

• É a maneira como o Git pensa sobre Outros Sistemas de Controle de

seus dados; Versão (Version Controle System – VCS)

12

12

6
 FORMA DE ARMAZENAR DADOS – OUTROS VCS

• Armazenam informações como

uma lista de mudanças
baseadas em arquivos;

• Controle de versão baseado Outros Sistemas de Controle de

em deltas. Versão (Version Controle System – VCS)

13

13

CONTROLE DE VERSÃO BASEADO EM DELTAS

CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

ARQUIVO A Δ 1A Δ 2A

ARQUIVO B Δ 1B Δ 2B

ARQUIVO C Δ 1C Δ 2C Δ 3C

14

14

7
 CONTROLE DE VERSÃO BASEADO EM DELTAS
CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

Versão Inicial
ARQUIVO A

A primeira versão de um arquivo

é armazenada na íntegra.
ARQUIVO B

ARQUIVO C

15

15

CONTROLE DE VERSÃO BASEADO EM DELTAS

Alterações
CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

• Quando uma nova versão do arquivo é

criada;
ARQUIVO A Δ 1A Δ 2A
• O sistema não armazena uma nova
cópia completa do arquivo.
ARQUIVO B Δ 1B Δ 2B
• Em vez disso, ele armazena apenas as
diferenças (Δ - deltas) entre a versão
anterior e a nova versão. ARQUIVO C Δ 1C Δ 2C Δ 3C

16

16

8
 CONTROLE DE VERSÃO BASEADO EM DELTAS
Recuperações
CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

• Para reconstruir uma versão específica

do arquivo;
ARQUIVO A Δ 1A Δ 2A
• O sistema aplica as diferenças
armazenadas (Δ - deltas) à versão inicial
ou a uma versão anterior; ARQUIVO B Δ 1B Δ 2B

• Até que a versão desejada seja

alcançada. ARQUIVO C Δ 1C Δ 2C Δ 3C

17

17

VANTAGENS - CONTROLE DE VERSÃO BASEADO EM DELTAS

CHECK-INS AO LONGO DO TEMPO

Eficiência no Armazenamento Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

• Como apenas as diferenças entre as

versões são armazenadas;
ARQUIVO A Δ 1A Δ 2A

• A quantidade de espaço em disco

utilizada é significativamente menor;
ARQUIVO B Δ 1B Δ 2B

• Em comparação com o armazenamento

de versões completas.
ARQUIVO C Δ 1C Δ 2C Δ 3C

18

18

9
 VANTAGENS - CONTROLE DE VERSÃO BASEADO EM DELTAS
CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

Facilidade de Comparação

• Comparar versões se torna mais ARQUIVO A Δ 1A Δ 2A

simples;

• Pois as mudanças são explícitas nos

ARQUIVO B Δ 1B Δ 2B

deltas.

ARQUIVO C Δ 1C Δ 2C Δ 3C

19

19

DESVANTAGENS - CONTROLE DE VERSÃO BASEADO EM DELTAS

CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

Complexidade na Recuperação

• A recuperação de versões mais antigas

ARQUIVO A Δ 1A Δ 2A
pode ser lenta;

• Já que pode exigir a aplicação de uma

série de deltas para reconstruir a versão ARQUIVO B Δ 1B Δ 2B

desejada.

ARQUIVO C Δ 1C Δ 2C Δ 3C

20

20

10
 DESVANTAGENS - CONTROLE DE VERSÃO BASEADO EM DELTAS
CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

Possibilidade de Erros
ARQUIVO A Δ 1A Δ 2A
• Se houver erros nos deltas;

• Pode ser difícil reconstruir versões

precisas dos arquivos. ARQUIVO B Δ 1B Δ 2B

ARQUIVO C Δ 1C Δ 2C Δ 3C

21

21

FORMA DE ARMAZENAR DADOS – GIT

• O Git utiliza uma abordagem

diferente do controle de versão
baseado em deltas;

• Ele utiliza a abordagem de controle

de versão baseado em snapshots.

22

22

11
 CONTROLE DE VERSÃO BASEADO EM SNAPSHOTS
CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

ARQUIVO A A1 A1 A2 A2

ARQUIVO B ARQUIVO B ARQUIVO B B1 B2

ARQUIVO C C1 C2 C2 C3

23

23

CONTROLE DE VERSÃO BASEADO EM SNAPSHOTS

CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

• Cada vez que você faz um

commit no Git;
ARQUIVO A A1 A1 A2 A2

• Ele tira um "snapshot" do estado

de todos os arquivos do seu
ARQUIVO B ARQUIVO B ARQUIVO B B1 B2
projeto naquele momento.

ARQUIVO C C1 C2 C2 C3

24

24

12
 CONTROLE DE VERSÃO BASEADO EM SNAPSHOTS
CHECK-INS AO LONGO DO TEMPO

• Se um arquivo não foi modificado Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

desde o último commit;

• O Git não armazena o arquivo ARQUIVO A A1 A1 A2 A2

novamente;

• Ele guarda um link para a versão ARQUIVO B ARQUIVO B ARQUIVO B B1 B2

anterior, que já está armazenada.

ARQUIVO C C1 C2 C2 C3

25

25

OBJETOS DO GIT
CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

• Blobs: Um Binary Large Object é o objeto

que armazena o conteúdo de um arquivo; ARQUIVO A A1 A1 A2 A2

• Cada arquivo no repositório é armazenado

como um blob. ARQUIVO B ARQUIVO B ARQUIVO B B1 B2

ARQUIVO C C1 C2 C2 C3

26

26

13
 OBJETOS DO GIT
CHECK-INS AO LONGO DO TEMPO

• Trees: é um objeto que representa um Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

diretório.

• Ela armazena a estrutura do diretório, ARQUIVO A A1 A1 A2 A2

incluindo:

• Os nomes dos arquivos;

ARQUIVO B ARQUIVO B ARQUIVO B B1 B2

• Links para os blobs correspondentes, ou

para outras trees em caso de subdiretórios.
ARQUIVO C C1 C2 C2 C3

27

27

OBJETOS DO GIT
• Commits: é um objeto que armazena CHECK-INS AO LONGO DO TEMPO

informações sobre uma alteração no Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

repositório, incluindo:

• Um ponteiro para a tree que representa o estado

ARQUIVO A A1 A1 A2 A2
do projeto naquele commit;

• O autor da alteração;
ARQUIVO B ARQUIVO B ARQUIVO B B1 B2
• Uma mensagem de commit;

• E um ponteiro para o commit anterior ou

commits anteriores, em caso de merges. ARQUIVO C C1 C2 C2 C3

28

28

14
 EFICIÊNCIA - CONTROLE DE VERSÃO BASEADO EM SNAPSHOTS
CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

• Embora o Git armazene

snapshots; ARQUIVO A A1 A1 A2 A2

• Ele é muito eficiente no uso de

espaço de armazenamento. ARQUIVO B ARQUIVO B ARQUIVO B B1 B2

ARQUIVO C C1 C2 C2 C3

29

29

EFICIÊNCIA - CONTROLE DE VERSÃO BASEADO EM SNAPSHOTS

CHECK-INS AO LONGO DO TEMPO
• Arquivos que não mudam entre commits
Versão 1 Versão 2 Versão 3 Versão 4 Versão 5
não são duplicados;

• Em vez disso, o Git referencia o mesmo

blob. ARQUIVO A A1 A1 A2 A2

• Além disso, o Git usa técnicas de

compactação e empacotamento ARQUIVO B ARQUIVO B ARQUIVO B B1 B2

• Para reduzir o tamanho dos dados

armazenados.
ARQUIVO C C1 C2 C2 C3

30

30

15
 DELTAS X SNAPSHOTS
Controle de Versão Baseado em Deltas Controle de Versão Baseado em Snapshots
CHECK-INS AO LONGO DO TEMPO CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5 Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

ARQUIVO A Δ 1A Δ 2A ARQUIVO A A1 A1 A2 A2

ARQUIVO B Δ 1B Δ 2B ARQUIVO B ARQUIVO B ARQUIVO B B1 B2

ARQUIVO C Δ 1C Δ 2C Δ 3C ARQUIVO C C1 C2 C2 C3

31

31

DELTAS X SNAPSHOTS
Controle de Versão Baseado em Deltas
CHECK-INS AO LONGO DO TEMPO

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

• Armazenam as diferenças entre versões;

ARQUIVO A Δ 1A Δ 2A
• O que significa que é necessário aplicar
as mudanças de uma versão anterior;

ARQUIVO B Δ 1B Δ 2B
• Para reconstruir uma versão específica.

ARQUIVO C Δ 1C Δ 2C Δ 3C

32

32

16
 DELTAS X SNAPSHOTS
• Armazenam o estado completo ou quase
Controle de Versão Baseado em Snapshots completo, de cada arquivo no momento do
CHECK-INS AO LONGO DO TEMPO commit.
Versão 1 Versão 2 Versão 3 Versão 4 Versão 5
• Mesmo que internamente o Git use alguns
métodos de compressão para reduzir
ARQUIVO A A1 A1 A2 A2 redundâncias;

• O conceito central é que cada commit

ARQUIVO B ARQUIVO B ARQUIVO B B1 B2 aponta para um snapshot do estado do
repositório;

ARQUIVO C C1 C2 C2 C3 • Não para um conjunto de deltas (variações

do arquivo).
33

33

OPERAÇÕES LOCAIS

• A maioria das operações no Git é local,

usando apenas arquivos e recursos no disco;

• Isso elimina a latência de rede.

• Operações como navegar pelo histórico ou

calcular diferenças entre versões

• São quase instantâneas, pois são feitas

localmente.

34

34

17
 INTEGRIDADE NO GIT

• No Git, checksums são usados para

identificar de forma única cada objeto no
repositório, como commits, blobs e trees,
etc.

• O Git utiliza o algoritmo SHA-1 para gerar

esses checksums.

35

35

CHECKSUM
• Checksums ou somas de verificação são valores
numéricos gerados a partir de um conjunto de
dados, por exemplo:
• Arquivo;
• Mensagem;
• Qualquer sequência de bits.
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
• Eles são usados para verificar a integridade dos
dados;

• Garantindo que os mesmos não foram alterados ou

corrompidos durante a transmissão ou
armazenamento.

36

36

18
 CHECKSUMS NO GIT
• Checksum SHA-1:
e69de29bb2d1d6434b8b29ae775ad8c2e48c53
91

• Este valor de 40 caracteres hexadecimais é o

checksum SHA-1 de um objeto específico no
repositório Git.

• Cada commit, arquivo (blob), árvore (tree), e

outros objetos Git têm um checksum SHA-1
exclusivo.

37

37

INTEGRIDADE NO GIT
• O Git pega o conteúdo do objeto;

• Por exemplo, o conteúdo de um arquivo ou as

informações de um commit;

• Aplica o algoritmo SHA-1 e gera o checksum.

• O checksum identifica unicamente o objeto,

• E qualquer alteração no conteúdo resultará em

um checksum diferente.

38

38

19
 IMPORTÂNCIA DO CHECKSUM NO GIT
• O checksum no Git garante a integridade dos
dados.

• Se um arquivo for alterado, seu checksum

mudará, o que significa que o Git pode
detectar alterações ou corrupções.

• Isso também ajuda o Git a identificar de forma

eficiente arquivos ou commits idênticos,

• Mesmo que estejam em diferentes branches

ou repositórios.

39

39

ADIÇÃO DE DADOS
• A maioria das ações no Git apenas adiciona
dados ao banco de dados;

• Tornando difícil perder informações após o

commit.

• O Git permite experimentação sem grande

risco de perda;

• Especialmente se você fizer push regularmente

para o repositório.

40

40

20
 STATUS DO GIT

Modificado

Preparado ou Indexado
(Staged)

Confirmado ou Comitado
(committed)

41

41

STATUS MODIFICADO
• O item de configuração foi alterado na área
de trabalho (working tree) do seu projeto;
Modificado
• Mas essas mudanças ainda não foram
registradas no controle de versão, ou seja, Preparado ou Indexado
(Staged)
não foram preparadas ou confirmadas;

• Exemplo: Se você abrir um arquivo, editar o Confirmado ou Comitado

(committed)
conteúdo, e salvar, ele estará com o status
modificado.

42

42

21
 STATUS PREPARADO OU INDEXADO (STAGED)

• Um arquivo preparado foi marcado para ser Modificado

incluído no próximo commit.
Preparado ou Indexado
• Isso significa que ele foi adicionado à área de (Staged)
preparação (staging area) do Git.
Confirmado ou Comitado
• O comando usado para isso é git add. (committed)

43

43

STATUS PREPARADO OU INDEXADO (STAGED)

• Exemplo: Após modificar um arquivo, você Modificado

executa git add <nome do arquivo>,
colocando-o na área de preparação. Preparado ou Indexado
(Staged)
• Agora ele está pronto para ser confirmado no
Confirmado ou Comitado
próximo commit. (committed)

44

44

22
 STATUS CONFIRMADO OU COMITADO

• Quando um arquivo é confirmado, as

Modificado
mudanças foram gravadas permanentemente
no repositório Git, no diretório Git (Git Preparado ou Indexado
directory). (Staged)

• Cada commit cria um novo "snapshot" do Confirmado ou Comitado

(committed)
projeto que o Git pode rastrear.

45

45

STATUS CONFIRMADO OU COMITADO

• Exemplo: Após preparar um arquivo, você Modificado

executa git commit -m "mensagem do
commit", Preparado ou Indexado
(Staged)
• O que confirma as mudanças no histórico do
Confirmado ou Comitado
repositório. (committed)

46

46

23
 AS 3 PRINCIPAIS SEÇÕES DE UM PROJETO GIT
Área de Preparação Diretório Git
Área de Trabalho
(Staging) (Repositório)

47

47

WORKING TREE (ÁRVORE DE TRABALHO OU ÁREA DE TRABALHO)

Área de Preparação Diretório Git

Área de Trabalho
(Staging) (Repositório)
• A árvore de trabalho é a cópia dos
arquivos do projeto que você está
atualmente editando.

• É o conjunto de arquivos e diretórios que

você vê e com os quais trabalha no seu
sistema de arquivos local.

48

48

24
 EXEMPLO - WORKING TREE

Área de Preparação Diretório Git

Área de Trabalho
(Staging) (Repositório)

• Quando você clona um repositório Git; Checkout do Projeto

• Os arquivos do projeto são extraídos

para a árvore de trabalho, onde você
pode editá-los.

49

49

STAGING AREA (ÁREA DE PREPARAÇÃO OU ÁREA DE STAGING)

Área de Preparação Diretório Git

Área de Trabalho
(Staging) (Repositório)

• A área de preparação é uma área

intermediária onde você coloca arquivos
que deseja incluir no próximo commit.

• É como um "buffer" que armazena as

mudanças que você quer confirmar.

50

50

25
 EXEMPLO - STAGING AREA

Área de Preparação Diretório Git

Área de Trabalho
(Staging) (Repositório)

• Ao adicionar um arquivo com git add;

• Você está movendo o arquivo da árvore Preparar as Alterações

de trabalho para a área de preparação.

51

51

GIT DIRECTORY (DIRETÓRIO GIT OU REPOSITÓRIO GIT)

Área de Preparação Diretório Git

Área de Trabalho
• O diretório Git é onde o Git armazena (Staging) (Repositório)

todos os metadados e o histórico do seu

projeto.

• Isso inclui os commits, objetos do Git

(como blobs e trees), e as configurações do
repositório.

• No diretório .git, você encontra tudo isso

52

52

26
 EXEMPLO - GIT DIRECTORY

Área de Preparação Diretório Git

Área de Trabalho
(Staging) (Repositório)

• Quando você inicializa um repositório Git

com git init;

• O diretório .git é criado, contendo todos

os arquivos necessários para o
funcionamento do Git.

53

53

FLUXO DE TRABALHO BÁSICO DO GIT

Área de Preparação Diretório Git
Área de Trabalho
(Staging) (Repositório)

Checkout do Projeto

Preparar as Alterações

commit

54

54

27
 WORKING TREE

Área de Preparação Diretório Git

Área de Trabalho
(Staging) (Repositório)

• Quando você clona um repositório Git; Checkout do Projeto

• Os arquivos do projeto são extraídos

para a árvore de trabalho, onde você
pode editá-los.

55

55

ETAPA 1 – MODIFIQUE OS ARQUIVOS

Área de Preparação Diretório Git

Área de Trabalho
(Staging) (Repositório)

• Primeiro, faça as correções nos arquivos

que precisam ser ajustados.

• Essas mudanças ocorrerão na árvore de

trabalho (working tree).

56

56

28
 ETAPA 2 - ADICIONE AS CORREÇÕES NA ÁREA DE PREPARAÇÃO

Área de Preparação Diretório Git

Área de Trabalho
(Staging) (Repositório)

• Depois de modificar os arquivos,

• Você precisa adicionar essas correções à área de

Preparar as Alterações
preparação (staging area)
git add
• Para que elas sejam incluídas no próximo commit.

• Para isso, você pode usar o comando git add.

57

57

ETAPA 2 - ADICIONE AS CORREÇÕES NA ÁREA DE PREPARAÇÃO

Área de Preparação Diretório Git

Área de Trabalho
(Staging) (Repositório)

• Se quiser adicionar todas as mudanças

corrigidas de uma vez, você pode usar: Preparar as Alterações

• git add . git add

• git add -A.

58

58

29
 ETAPA 3 – VERIFIQUE O STATUS

Área de Preparação Diretório Git

Área de Trabalho
(Staging) (Repositório)

• Antes de fazer o commit, é uma boa prática

verificar o que foi adicionado à área de
preparação usando o comando git status.

• Isso mostrará quais arquivos estão preparados e

quais ainda estão modificados, mas não
preparados.
git status

59

59

ETAPA 4 – FAÇA COMMIT DAS CORREÇÕES

Área de Preparação Diretório Git

Área de Trabalho
(Staging) (Repositório)

• Após verificar que tudo está preparado

corretamente;

• Você pode confirmar as correções com um

commit, usando o comando git commit. commit

60

60

30
 LINHA DE COMANDO

• O Git no terminal oferece acesso a toda a

gama de funcionalidades do Git.

• Nem todas as interfaces gráficas suportam

todos os comandos e opções avançadas.

61

61

LINHA DE COMANDO

• No terminal, você pode executar qualquer

comando Git;

• Incluindo aqueles mais específicos ou

complexos;

• Que podem não estar disponíveis ou serem

difíceis de localizar na interface gráfica.

62

62

31
 LINHA DE COMANDO

• Para desenvolvedores experientes, o uso do

terminal pode ser mais rápido;

• Pois permite a execução rápida de comandos

sem a necessidade de navegar por menus ou
clicar em várias opções;

• Um comando digitado no terminal pode

executar várias operações de uma só vez.

63

63

NOÇÕES BÁSICAS
Do GIT

64

64

32
 REPOSITÓRIO GIT

Um repositório Git é um diretório que

contém:

• Todos os arquivos do seu projeto;

• O histórico de revisões (versões) de

cada arquivo;

65

65

FORMAS DE OBTER UM REPOSITÓRIO GIT

1. Transformar um diretório local não

versionado em um repositório Git.

2. Clonar um repositório Git existente de

outra fonte.

66

66

33
 1. INICIALIZAR UM NOVO REPOSITÓRIO

REPOSITÓRIO

Transformar

Diretório Diretório
Local Git

67

67

1. INICIALIZAR UM NOVO REPOSITÓRIO

Linux

$ cd /home/user/meu-projeto

1. Abra o terminal do seu computador;

MacOS
2. Acesse o diretório do projeto que $ cd /Users/user/meu-projeto
deseja versionar.
Windows

$ cd C:/Users/user/meu-projeto

68

68

34
 1. INICIALIZAR UM NOVO REPOSITÓRIO
Use o comando: git init

• Este comando cria um novo repositório Git

em um diretório existente.

• Ele cria um subdiretório .git que contém

todos os arquivos necessários para o git init
controle de versão do Git.

• É usado para começar a versionar um projeto

existente que ainda não é controlado pelo
Git.

69

69

EXEMPLO - INICIALIZAR UM NOVO REPOSITÓRIO

mkdir meu-projeto
cd meu-projeto
git init

70

70

35
 2. CLONAR UM NOVO REPOSITÓRIO

REPOSITÓRIO

Clonar

Diretório Diretório
Local Git

71

71

2. CLONAR UM NOVO REPOSITÓRIO

Use o comando: git clone <url>

• Este comando cria uma cópia local de um

repositório Git existente.

• A URL pode ser de um caminho local ou de git clone <url>

um repositório remoto, por exemplo:

• Bitbucket
• GitHub
• GitLab

72

72

36
 2. CLONAR UM NOVO REPOSITÓRIO

• O Git cria um diretório no seu sistema de

arquivos;

• Coloca todos os arquivos do projeto; git clone <url>

• E configura o repositório Git localmente para
trabalhar com o repositório remoto.

73

73

EXEMPLO - CLONAR UM NOVO REPOSITÓRIO

git clone [Link]

• Clona o repositório do Kernel do Linux no Github;

• Cria um diretório linux com o repositório clonado em sua máquina.

74

74

37
 EXEMPLO - CLONAR UM NOVO REPOSITÓRIO

git clone [Link] projeto-linux

• Se você quiser clonar o repositório em uma pasta com um nome

diferente;

• Você pode especificar o novo nome da pasta como um argumento

adicional no comando git clone

• O comando acima, cria um diretório projeto-linux com o

repositório clonado em sua máquina.

75

75

CICLO DE VIDA DOS STATUS DOS ARQUIVOS NO REPOSITÓRIO GIT

Não Rastreado Não Modificado Modificado Preparado

Staged

76

76

38
 NÃO RASTREADO (UNTRACKED)
Não Rastreado Não Modificado Modificado Preparado (Staged)

• O arquivo existe na árvore de

trabalho;

• Mas o Git não está rastreando ele.

• Isso significa que ele não foi

adicionado à área de preparação.

77

77

NÃO RASTREADO (UNTRACKED)

Não Rastreado Não Modificado Modificado Preparado (Staged)

• Neste status você deve adicionar o

arquivo para a área de preparação;

• Através do comando git add

Adicionar o
Arquivo
• O arquivo mudará o status de Não
Rastreado para Preparado (Staged)

78

78

39
 NÃO MODIFICADO (UNMODIFIED)
Não Rastreado Não Modificado Modificado Preparado (Staged)

• O arquivo está sendo rastreado

pelo Git;

• Mas não foi alterado desde o último

commit.

commit

79

79

NÃO MODIFICADO (UNMODIFIED)

Não Rastreado Não Modificado Modificado Preparado (Staged)

• Você pode editar o arquivo;

• O arquivo mudará o status de Não

Modificado para Modificado

Editar o Arquivo

80

80

40
 NÃO MODIFICADO (UNMODIFIED)
Não Rastreado Não Modificado Modificado Preparado (Staged)

• Você pode remover o arquivo;

• O arquivo mudará o status de Não

Modificado para Não Rastreado

Remover o
Arquivo

81

81

MODIFICADO (MODIFIED)
Não Rastreado Não Modificado Modificado Preparado (Staged)

• O arquivo foi alterado na árvore

de trabalho

• Mas ainda não foi preparado para

o commit.

82

82

41
 MODIFICADO (MODIFIED)
Não Rastreado Não Modificado Modificado Preparado (Staged)

• Neste status você deve adicionar o

arquivo para a área de
preparação;

• Através do comando git add

• O arquivo mudará o status de

Modificado para Preparado Adicionar o
Arquivo
(Staged)

83

83

PREPARADO (STAGED)
Não Rastreado Não Modificado Modificado Preparado (Staged)

• O arquivo modificado foi

adicionado à área de preparação;

• E está pronto para ser incluído no

próximo commit.

84

84

42
 RASTREAR NOVOS ARQUIVOS

• Este comando adiciona alterações na

árvore de trabalho (os arquivos que
você está editando);
git add <arquivo>
• À área de preparação (staging area);

• Isso prepara os arquivos para o git add [Link]

próximo commit.

85

85

RASTREAR NOVOS ARQUIVOS

Para adicionar todos os arquivos

git add .
modificados de uma vez, use

86

86

43
 REMOVENDO ARQUIVOS

Como dizer ao Git para não

rastrear mais um arquivo ou
conjunto de arquivos?

87

87

REMOVENDO ARQUIVOS

• O comando git rm é usado para

remover arquivos de um repositório
do Git. git rm <arquivo>
• Ele pode ser considerado como o
inverso do comando git add.

88

88

44
 VERIFICAR O STATUS DOS ARQUIVOS

Use o comando: git status

• Este comando mostra o estado atual da

árvore de trabalho e da área de preparação.
git status
• Ele indica quais arquivos foram modificados;

• Quais estão prontos para o commit;

• E quais não estão sendo rastreados.

89

89

VERIFICAR O STATUS DOS ARQUIVOS

• Se você executar esse comando diretamente
após um clone;

• Ele mostrará que você tem um diretório de

trabalho limpo;

• Ou seja, nenhum dos seus arquivos

rastreados foi modificado.

• O Git também não vê nenhum arquivo não

rastreado, caso contrário eles seriam listados

90

90

45
 EXEMPLO - VERIFICAR O STATUS DOS ARQUIVOS
git status

On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: [Link]

Changes not staged for commit:

(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: [Link]
modified: [Link]

Untracked files:
(use "git add <file>..." to include in what will be committed)
[Link]

91

91

EXEMPLO - VERIFICAR O STATUS DOS ARQUIVOS

Novo arquivo preparado para git status

commit. On branch main

Changes to be committed:
(use "git restore --staged <file>..." to unstage)
• O arquivo [Link] foi criado new file: [Link]

Changes not staged for commit:

e adicionado à área de preparação (use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
(staging area) usando git add modified:
modified:
[Link]
[Link]

Untracked files:
• Está pronto para ser confirmado (use "git add <file>..." to include in what will be committed)
[Link]
(commit)

92

92

46
 EXEMPLO - VERIFICAR O STATUS DOS ARQUIVOS

git status

On branch main
Changes to be committed:
Arquivos Modificados, mas não (use "git restore --staged <file>..." to unstage)
new file: [Link]
preparados Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
• [Link] modified: [Link]
modified: [Link]
• [Link]
Untracked files:
(use "git add <file>..." to include in what will be committed)
[Link]

93

93

EXEMPLO - VERIFICAR O STATUS DOS ARQUIVOS

git status
• Esses dois arquivos foram On branch main
Changes to be committed:
modificados na árvore de (use "git restore --staged <file>..." to unstage)
new file: [Link]
trabalho (working tree), Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
• Mas as mudanças ainda não modified: [Link]
modified: [Link]
foram adicionadas à área de
Untracked files:
(use "git add <file>..." to include in what will be committed)
preparação. [Link]

94

94

47
 EXEMPLO - VERIFICAR O STATUS DOS ARQUIVOS

• Isso significa que, se você git status

fizer um commit agora; On branch main

Changes to be committed:
(use "git restore --staged <file>..." to unstage)
• Essas modificações não new file: [Link]

Changes not staged for commit:

serão incluídas. (use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: [Link]
• Para adicionar essas modified: [Link]

Untracked files:
mudanças à área de (use "git add <file>..." to include in what will be committed)
[Link]
preparação, use git add

95

95

EXEMPLO - VERIFICAR O STATUS DOS ARQUIVOS

git status

Arquivos Não Rastreados On branch main

Changes to be committed:
(use "git restore --staged <file>..." to unstage)
• O arquivo [Link] foi new file: [Link]

Changes not staged for commit:

criado; (use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: [Link]
• Mas ainda não foi adicionado ao modified: [Link]

Untracked files:
controle de versão do Git. (use "git add <file>..." to include in what will be committed)
[Link]

96

96

48
 EXEMPLO - VERIFICAR O STATUS DOS ARQUIVOS

git status
• O Git não está rastreando este
On branch main
arquivo, Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: [Link]
• O que significa que ele não será Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
incluído em um commit (use "git restore <file>..." to discard changes in working directory)
modified: [Link]
modified: [Link]
• Até que seja adicionado à área de Untracked files:
(use "git add <file>..." to include in what will be committed)
preparação com o git add [Link]

97

97

EXEMPLO - VERIFICAR O STATUS DOS ARQUIVOS

• [Link] foi criado e já está na
área de preparação, pronto para ser
git status
comitado. On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
• [Link] e [Link] foram new file: [Link]

modificados, mas não estão Changes not staged for commit:

(use "git add <file>..." to update what will be committed)
preparado para commit. (use "git restore <file>..." to discard changes in working directory)
modified: [Link]
modified: [Link]
• [Link] é um novo
Untracked files:
arquivo não rastreado pelo Git. Ele (use "git add <file>..." to include in what will be committed)
[Link]
precisa ser adicionado para ser
incluído em um commit futuro.

98

98

49
 VERSÃO ABREVIADA DO COMANDO VERIFICAR O STATUS

• Fornece uma visão mais compacta e concisa

do estado dos arquivos no repositório,

• Exibindo apenas os arquivos que têm git status --short

mudanças, sem o texto explicativo adicional.
git status -s
• Essa saída mais compacta é útil para quem
deseja uma visão rápida do que mudou.

99

99

VERSÃO ABREVIADA DO COMANDO VERIFICAR O STATUS

• A saída do comando é composta por duas

colunas de símbolos e o nome do arquivo.

• Esses símbolos indicam o status dos git status --short

arquivos em relação à
git status -s
• Área de preparação (staging area)
• Árvore de trabalho (working tree)

100

100

50
 EXEMPLO
• ' ' = não modificado
• M = modificado
• T = tipo de arquivo alterado (arquivo regular,
link simbólico ou submódulo) git status -s
• A = adicionado
M [Link]
• D = excluído AM [Link]
• R = renomeado ?? [Link]
• C = copiado (se a opção de configuração
[Link] estiver definida como "cópias")
• U = atualizado, mas não mesclado

101

101

EXEMPLO

• Coluna 1 (Espaço Vazio): o arquivo

[Link] não tem mudanças adicionadas à
git status -s
área de preparação.

• Coluna 2 (M): o arquivo [Link] foi M [Link]

AM [Link]
modificado na árvore de trabalho (working
?? [Link]
tree), mas essas modificações ainda não foram
preparadas (staged) para o commit.

102

102

51
 EXEMPLO
• Coluna 1 (A): o arquivo [Link] foi
adicionado à área de preparação (staged)
como um novo arquivo.
git status -s
• Coluna 2 (M): após o arquivo [Link]
ter sido adicionado à área de preparação, ele M [Link]
AM [Link]
foi modificado novamente na árvore de
?? [Link]
trabalho (working tree). As modificações mais
recentes ainda não foram adicionadas à área
de preparação.

103

103

EXEMPLO

• Indica que o arquivo [Link] é

um arquivo novo e não rastreado pelo Git.
git status -s
• Ele existe na árvore de trabalho, mas ainda
não foi adicionado ao controle de versão do M [Link]
Git
AM [Link]
?? [Link]
• Ou seja, não foi adicionado à área de
preparação.

104

104

52
 IGNORANDO ARQUIVOS NO GIT

• Se você tem arquivos que não deseja que o

Git rastreie como:

• Arquivos de configuração locais

• Arquivos temporários, logs, etc.

• Você pode ignorá-los usando um arquivo

chamado .gitignore.

105

105

IGNORANDO ARQUIVOS NO GIT

1. Ignora todos os arquivos .log

2. Ignora um arquivo específico

1 *.log
3. Ignora um diretório chamado temp 2 config/[Link]
3 temp/
4. Ignora qualquer arquivo terminado em
4 *.[oa]
.o ou .a
5 *~
5. Ignora todos os arquivos cujo nome
termina com til ~

106

106

53
 EXEMPLO - .GITIGNORE
# Ignore todos os arquivos .a
*.a

# Mas rastreie lib.a, mesmo que você esteja ignorando os arquivos .a acima
!lib.a

# ignore todos os arquivos em qualquer diretório chamado build

build/

# ignore doc/[Link], mas não doc/server/[Link]

doc/*.txt

# ignore todos os arquivos .pdf no diretório doc/ e em qualquer um de seus subdiretórios

doc/**/*.pdf

107

107

VISUALIZAR AS MUDANÇAS FEITAS NOS ARQUIVOS

• O Git permite que você veja as mudanças que
foram feitas em seus arquivos.

• Essas mudanças podem estar na :

• Árvore de trabalho (Working Tree)

• Área de preparação (Staging Area)

• Ele mostra as diferenças entre os arquivos

em termos de linhas adicionadas e
removidas.

108

108

54
 VISUALIZAR MUDANÇAS NOS ARQUIVOS DA ÁRVORE DE TRABALHO
• Para ver as diferenças entre:

• A última versão confirmada (committed);

• As mudanças atuais que não foram

preparadas para commit.
git diff
• O comando mostrará as linhas de código
que foram: adicionadas, removidas ou
modificadas;

• Em seus arquivos na árvore de trabalho.

109

109

EXEMPLO – GIT DIFF

• Após criar e inicializar um
repositório git;

• Foi criado o arquivo [Link]

e adicionado o código html básico; git add [Link]

• O arquivo foi adicionado para git commit -m "Arquivo [Link] adicionado"

rastreamento do git;

• E, as mudanças foram efetivadas

(comitadas) no repositório.

110

110

55
 EXEMPLO – GIT DIFF
git diff

diff --git a/[Link] b/[Link]

index e69de29..73f1ab0 100644
• Esse comando mostra as diferenças entre --- a/[Link]
+++ b/[Link]
• Os arquivos modificados na sua área de @@ -0,0 +1,10 @@
+<!DOCTYPE html>
trabalho +<html lang="pt-BR">
+<head>
• Que ainda não foram adicionados à área + <meta charset="UTF-8">
+ <title>Home</title>
de preparação +</head>
+<body>
• E a última versão comitada +
+</body>
+</html>
\ No newline at end of file

111

111

EXEMPLO – GIT DIFF

git diff

diff --git a/[Link] b/[Link]

index e69de29..73f1ab0 100644
--- a/[Link]
• Indica que o comando está comparando a +++ b/[Link]
@@ -0,0 +1,10 @@
versão do arquivo [Link] +<!DOCTYPE html>
+<html lang="pt-BR">
+<head>
• Antes (a/[Link]) + <meta charset="UTF-8">
+ <title>Home</title>
• E depois (b/[Link]) das alterações +</head>
+<body>
+
+</body>
+</html>
\ No newline at end of file

112

112

56
 EXEMPLO – GIT DIFF
git diff
• Mostra os hashes dos commits (ou dos diff --git a/[Link] b/[Link]
index e69de29..73f1ab0 100644
estados do arquivo) que estão sendo --- a/[Link]
+++ b/[Link]
comparados;
@@ -0,0 +1,10 @@
+<!DOCTYPE html>
• e69de29 refere-se à versão anterior do +<html lang="pt-BR">
+<head>
arquivo; + <meta charset="UTF-8">
+ <title>Home</title>
• 73f1ab0 refere-se à nova versão; +</head>
+<body>
• 100644 refere-se às permissões do +
+</body>
arquivo (arquivo regular). +</html>
\ No newline at end of file

113

113

EXEMPLO – GIT DIFF

git diff

diff --git a/[Link] b/[Link]

index e69de29..73f1ab0 100644
• --- a/[Link]: Esta linha indica que --- a/[Link]
+++ b/[Link]
o conteúdo mostrado a seguir é do arquivo @@ -0,0 +1,10 @@
+<!DOCTYPE html>
original (a/[Link]). +<html lang="pt-BR">
+<head>
• +++ b/[Link]: Esta linha indica que + <meta charset="UTF-8">
+ <title>Home</title>
o conteúdo mostrado a seguir é do arquivo +</head>
+<body>
modificado (b/[Link]). +
+</body>
+</html>
\ No newline at end of file

114

114

57
 EXEMPLO – GIT DIFF
git diff
• Esta linha é um “chunk header" que mostra diff --git a/[Link] b/[Link]
o contexto das mudanças; index e69de29..73f1ab0 100644
--- a/[Link]
+++ b/[Link]
• Ela significa que, na versão original @@ -0,0 +1,10 @@
+<!DOCTYPE html>
(a/[Link]), não havia conteúdo (o +<html lang="pt-BR">
+<head>
arquivo estava vazio ou não existia); + <meta charset="UTF-8">
+ <title>Home</title>
• enquanto na nova versão (b/[Link]), 10 +</head>
+<body>
linhas foram adicionadas começando na +
+</body>
linha 1. +</html>
\ No newline at end of file

115

115

EXEMPLO – GIT DIFF

git diff

diff --git a/[Link] b/[Link]

index e69de29..73f1ab0 100644
--- a/[Link]
+++ b/[Link]
@@ -0,0 +1,10 @@
As linhas que começam com + +<!DOCTYPE html>
+<html lang="pt-BR">
mostram o conteúdo que foi +<head>
+ <meta charset="UTF-8">
adicionado ao arquivo [Link] + <title>Home</title>
+</head>
+<body>
+
+</body>
+</html>
\ No newline at end of file

116

116

58
 VISUALIZAR MUDANÇAS NOS ARQUIVOS DA ÁREA DE PREPARAÇÃO

• Para ver as mudanças que foram

adicionadas à área de preparação;
git diff --staged
• Mas que ainda não foram confirmadas;
OU
• Esse comando mostra as diferenças entre
a última versão confirmada ; git diff --cached
• E as alterações que foram preparadas
para o próximo commit.

117

117

EXEMPLO – GIT DIFF --STAGED

git diff --staged
diff --git a/[Link] b/[Link]
index 73f1ab0..cffdc97 100644
• O resultado é semelhante ao de git
--- a/[Link]
diff
+++ b/[Link]
@@ -6,6 +6,6 @@
• Mas reflete as mudanças que estão
<title>Home</title>
prestes a serem comitadas;
</head>

• Ou seja, que foram recém adicionadas à <body>

-
área de preparação com git add .
+ <h1>Home</h1>
</body>
</html>
\ No newline at end of file

118

118

59
 COMPARANDO ARQUIVOS DE 2 COMMITS DIFERENTES

• Esse comando compara 2 commits

específicos;
git diff [commit 1] [commit 2]
• Mostrando as diferenças dos arquivos
entre eles.

119

119

COMPARANDO ARQUIVOS DE 2 COMMITS DIFERENTES

git diff e69de29 cffdc97

diff --git a/e69de29 b/cffdc97

index e69de29..cffdc97 100644
--- a/e69de29
• Neste exemplo estamos visualizando as +++ b/cffdc97
@@ -0,0 +1,10 @@
mudanças nos arquivos entre dois +<!DOCTYPE html>
+<html lang="pt-BR">
commits +<head>
+ <meta charset="UTF-8">
1. e69de29 + <title>Home</title>
+</head>
2. cffdc97. +<body>
+ <h1>Home</h1>
+</body>
+</html>
\ No newline at end of file

120

120

60
 efetivando
As Mudanças

121

121

COMMIT
• Um commit no Git é um instantâneo do
estado do seu projeto em um dado
momento.

• Quando você faz um commit,

git commit
• Você está gravando o estado atual dos
arquivos que foram adicionados à área de
preparação (staging area) no histórico do
repositório.

122

122

61
 REALIZANDO O COMMIT DAS SUAS MUDANÇAS
• Após configurar a área de preparação
(staging)

• Use git commit para gravar as mudanças.

Apenas os arquivos que foram adicionados à

•
git commit
staging serão incluídos no commit.

• Arquivos não incluídos na staging

permanecerão modificados no disco, mas
fora do commit.

123

123

EXEMPLO 1 - COMMIT
git 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
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
# new file: README
# modified: [Link]
#
~
~
~
".git/COMMIT_EDITMSG" 9L, 283C

124

124

62
 EXEMPLO 1 - COMMIT

• O jeito mais simples de fazer commit é git commit

digitando git commit.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
• O editor padrão configurado abrirá # On branch master
# Your branch is up-to-date with 'origin/master'.
#
• E, exibirá um texto padrão # Changes to be committed:
# new file: README
# modified: [Link]
#
• Com a última saída do comando git ~
~
status como comentários. ~
".git/COMMIT_EDITMSG" 9L, 283C

125

125

EXEMPLO 1 - COMMIT

• Você pode remover os comentários e

git commit
digitar sua mensagem de commit;
# Please enter the commit message for your changes. Lines starting
• Ou deixá-los para ajudar a lembrar o que # with '#' will be ignored, and an empty message aborts the commit.
# On branch master
está comitando; # Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
# new file: README
• Ao sair do editor, o Git cria o commit com # modified: [Link]
#
sua mensagem; ~
~
~
• Os comentários serão removidos. ".git/COMMIT_EDITMSG" 9L, 283C

126

126

63
 REALIZANDO O COMMIT DAS SUAS MUDANÇAS

• A flag -m permite que você inclua uma

mensagem de commit diretamente no
comando. git commit -m "Mensagem"
• Essa mensagem deve descrever de forma
clara o que foi feito nesse commit.

127

127

EXEMPLO 2 - COMMIT

git commit -m “História 182: correção de desempenho”

[master 463dc4f] História 182: correção de desempenho

2 files changed, 2 insertions(+)
create mode 100644 README

128

128

64
 COMMIT SEM GIT ADD

• Se você deseja fazer o commit de todas as

mudanças nos arquivos rastreados;
git commit -a -m "Mensagem"
• Sem precisar primeiro usar git add

• Você pode usar a opção -a

129

129

EDITANDO A MENSAGEM DO COMMIT ANTERIOR

• Se você cometeu um erro na mensagem

do último commit;
git commit --amend -m "Mensagem"
• Pode usar a opção --amend para
modificar o commit mais recente

130

130

65
 ESPECIFICAÇÃO DO CONVENTIONAL COMMITS

• Convenção simples para utilizar nas

mensagens de commit;

• Define um conjunto de regras para criar

um histórico de commit explícito;
[Link]
• O que facilita a criação de ferramentas
automatizadas.

131

131

ESPECIFICAÇÃO DO CONVENTIONAL COMMITS

• Esta convenção segue o Versionamento

Semântico (SemVer);

• Descrevendo: os recursos, correções e

modificações que quebram a
compatibilidade; [Link]

• Nas mensagens de commit.

132

132

66
 ESPECIFICAÇÃO DO CONVENTIONAL COMMITS

Cada mensagem de commit consiste

em um: <cabeçalho>
<LINHA EM BRANCO>
• Cabeçalho; <corpo>
<LINHA EM BRANCO>
• Corpo; <rodapé>

• Rodapé.

133

133

ESPECIFICAÇÃO DO CONVENTIONAL COMMITS

<tipo>([escopo opcional]): <descrição>

[corpo opcional]

[rodapé opcional]

134

134

67
 CABEÇALHO - CONVENTIONAL COMMITS

• O cabeçalho é obrigatório <tipo>([escopo opcional]): <descrição>

• Deve estar em conformidade com o
[corpo opcional]
formato do Cabeçalho da Mensagem de
[rodapé opcional]
Commit.

135

135

TIPO DE COMMIT - CONVENTIONAL COMMITS

O tipo de commit deve ser algum dos seguintes
valores:
• build
• ci
• docs <tipo>([escopo opcional]): <descrição>

• feat [corpo opcional]

• fix
[rodapé opcional]
• perf
• refactor
• test
• chore
• style

136

136

68
 TIPO DE COMMIT - CONVENTIONAL COMMITS

• build: Alterações que afetam o sistema de

build ou dependências externas

• Exemplos de Escopos: gulp, broccoli, npm; <tipo>([escopo opcional]): <descrição>

• ci: Alterações em nossos arquivos de [corpo opcional]

configuração e scripts de CI; [rodapé opcional]

• Exemplos: CircleCi, SauceLabs

• docs: Alterações somente na documentação;

137

137

ESCOPO - CONVENTIONAL COMMITS

• feat: Um novo recurso;

• fix: Uma correção de bug;

<tipo>([escopo opcional]): <descrição>
• perf: Uma alteração de código que melhora [corpo opcional]
o desempenho;
[rodapé opcional]
• refactor: Uma alteração de código que não
corrige um bug nem adiciona um recurso;

138

138

69
 ESCOPO - CONVENTIONAL COMMITS

• test: Adicionar testes ausentes ou corrigir

testes existentes.

• chore: Para mudanças menores que não <tipo>([escopo opcional]): <descrição>

afetam o código; [corpo opcional]

• Exemplo: atualizações de dependências. [rodapé opcional]

• style: Para mudanças de formatação ou

estilo que não afetam o código funcional.

139

139

ESCOPO - CONVENTIONAL COMMITS

• Especifica a parte do código que foi alterada

• Por exemplo, um módulo ou componente

<tipo>([escopo opcional]): <descrição>
específico:
[corpo opcional]
• animations
• auth [rodapé opcional]

• core
• lang

140

140

70
 DESCRIÇÃO - CONVENTIONAL COMMITS

• Um resumo breve do que foi feito;

<tipo>([escopo opcional]): <descrição>
• No tempo presente (Modo Imperativo);
[corpo opcional]
• Em minúsculo;
[rodapé opcional]
• Sem ponto final.

141

141

CORPO - CONVENTIONAL COMMITS

• Explique a motivação para a mudança no
corpo da mensagem de commit.

• Esta mensagem de commit deve explicar <tipo>[escopo opcional]: <descrição>

por que você está fazendo a mudança.
[corpo opcional]
• Você pode incluir uma comparação do [rodapé opcional]
comportamento anterior com o novo
comportamento para ilustrar o impacto
da mudança.

142

142

71
 RODAPÉ - CONVENTIONAL COMMITS
• Informações sobre alterações significativas e
descontinuações

• Também é o local para referenciar

<tipo>[escopo opcional]: <descrição>
problemas do GitHub, tickets do Jira
[corpo opcional]
• E outros PRs que este commit fecha ou está
[rodapé opcional]
relacionado.

• Exemplo: Números de pull request ou

tickts;

143

143

EXEMPLOS - CONVENTIONAL COMMITS

fix: corrige pequenos erros de

digitação no código

Veja o ticket para detalhes sobre os

erros de digitação corrigidos

closes issue #12

Mensagem de commit de uma correção utilizando

número de ticket no rodapé (opcional)

144

144

72
 EXEMPLOS - CONVENTIONAL COMMITS

feat: permitir que o objeto de configuração

fornecido estenda outras configurações

BREAKING CHANGE: a chave extends, no arquivo

de configuração, agora é utilizada
para estender outro arquivo de configuração

Mensagem de commit com descrição e modificação

que quebra a compatibilidade no corpo

145

145

EXEMPLOS - CONVENTIONAL COMMITS

chore!: remove Node 6 da matriz de testes

BREAKING CHANGE: removendo Node 6 que atinge o final de

vida em Abril

Mensagem de commit com ! (opcional), para

chamar a atenção para quebra a compatibilidade

146

146

73
 EXEMPLOS - CONVENTIONAL COMMITS

feat(lang): adiciona tradução para o português brasileiro

Mensagem de commit com escopo

147

147

EXEMPLOS - CONVENTIONAL COMMITS

docs: ortografia correta de CHANGELOG

Mensagem de commit sem escopo

148

148

74
 CONVENTIONAL COMMITS X VERSIONAMENTO SEMÂNTICO

4.2.1
Major Minor Patch
[Link]
[Link]

149

149

VERSIONAMENTO SEMÂNTICO

• Atualmente é o esquema de versionamento

mais conhecido e utilizado

• Utiliza uma sequência de três números 4.2.1

([Link]) Major Minor Patch
• E opcionalmente um rótulo de pré-
lançamento ou metadados.

150

150

75
 VERSIONAMENTO SEMÂNTICO

Sempre que ocorrerem

mudanças não compatíveis com
4.2.1
Major Minor Patch
versões anteriores

151

151

CONVENTIONAL COMMITS X VERSIONAMENTO SEMÂNTICO

• Um commit que contém a palavra BREAKING
CHANGE;

• No começo do texto do corpo ou do rodapé;

• Ou possui um ! após o tipo/escopo

• Introduz uma modificação que quebra a

4.2.1
compatibilidade da API; Major Minor Patch
• Se correlaciona com MAJOR do versionamento
semântico;

• Pode fazer parte de commits de qualquer tipo.

152

152

76
 VERSIONAMENTO SEMÂNTICO

Quando há adição de
funcionalidade compatível com
4.2.1
Major Minor Patch
versões anteriores

153

153

CONVENTIONAL COMMITS X VERSIONAMENTO SEMÂNTICO

• feat: um commit do tipo feat inclui um

novo recurso na sua base de código;
4.2.1
• Se correlaciona com MINOR do Major Minor Patch
versionamento semântico.

154

154

77
 VERSIONAMENTO SEMÂNTICO

Para todos os outros tipos de

mudanças, incluindo ajustes de 4.2.1
bugs, também compatíveis com Major Minor Patch
versões anteriores.

155

155

CONVENTIONAL COMMITS X VERSIONAMENTO SEMÂNTICO

• fix: um commit do tipo fix soluciona um

problema na sua base de código;
4.2.1
• Isso se correlaciona com PATCH do Major Minor Patch
versionamento semântico;

156

156

78
 PORQUE USAR O CONVENTIONAL COMMITS?

• Criação automatizada de CHANGELOGs.

• Determinar automaticamente um aumento de

versionamento semântico (com base nos tipos
de commits).

• Comunicar a natureza das mudanças para

[Link]
colegas de equipe, o público e outras partes
interessadas.

157

157

PORQUE USAR O CONVENTIONAL COMMITS?

• Disparar processos de build e deploy;

• Facilitar a contribuição de outras pessoas

em seus projetos;

• Permitindo que eles explorem um

histórico de commits mais estruturado. [Link]

158

158

79
 VISUALIZANDO O HISTÓRICO DE COMMITS

• O comando git log é uma das

ferramentas mais poderosas do Git;

• Para navegar e explorar o histórico de

git log
commits do repositório.

159

159

VISUALIZANDO O HISTÓRICO DE COMMITS

Ele permite que você veja

• As mudanças que foram feitas ao longo do
tempo;

• Quem as fez;
git log
• Quando foram feitas;

• E as mensagens associadas a cada commit.

160

160

80
 VISUALIZANDO O HISTÓRICO DE COMMITS
commit ca82a6dff817ec66f44342007202690a93763949 (HEAD -> master, origin/master, origin/HEAD)
Author: Scott Chacon <schacon@[Link]>
Date: Mon Mar 17 21:52:11 2008 -0700

changed the verison number

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <schacon@[Link]>
Date: Sat Mar 15 16:40:33 2008 -0700
git log
removed unnecessary test code

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <schacon@[Link]>
Date: Sat Mar 15 10:31:28 2008 -0700

161

161

VISUALIZANDO O HISTÓRICO DE COMMITS

commit ca82a6dff817ec66f44342007202690a93763949 (HEAD
• O git log exibe os commits em -> master, origin/master, origin/HEAD)

ordem cronológica reversa com os mais Author: Scott Chacon <schacon@[Link]>

Date: Mon Mar 17 21:52:11 2008 -0700
recentes primeiro.
changed the verison number

• Mostra o checksum SHA-1; commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7

Author: Scott Chacon <schacon@[Link]>
Date: Sat Mar 15 16:40:33 2008 -0700
• O autor;
removed unnecessary test code
• A data;
commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <schacon@[Link]>
• E a mensagem de commit. Date: Sat Mar 15 10:31:28 2008 -0700

162

162

81
 VISUALIZANDO O HISTÓRICO DE COMMITS

• Além das informações padrão;

git log --patch
• Mostra as diferenças introduzidas por
cada commit (o diff);
OU

• Isso é útil para ver exatamente o que foi git log -p

mudado em cada commit.

163

163

VISUALIZANDO O HISTÓRICO DE COMMITS

commit ca82a6dff817ec66f44342007202690a93763949 (HEAD -> master,
origin/master, origin/HEAD)

Author: Scott Chacon <schacon@[Link]>

Date: Mon Mar 17 21:52:11 2008 -0700

changed the verison number

git log --patch
diff --git a/Rakefile b/Rakefile
index a874b73..8f94139 100644
--- a/Rakefile OU
+++ b/Rakefile
@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
spec = Gem::[Link] do |s|
[Link] = Gem::Platform::RUBY
git log -p
[Link] = "simplegit"
- [Link] = "0.1.0"
+ [Link] = "0.1.1"
[Link] = "Scott Chacon"
[Link] = "schacon@[Link]"
[Link] = "A simple gem for using Git in Ruby code."

164

164

82
 VISUALIZANDO O HISTÓRICO DE COMMITS

• Mostra um resumo das mudanças feitas

em cada commit;
git log --stat
• Incluindo o número de linhas adicionadas
e removidas em cada arquivo.

165

165

VISUALIZANDO O HISTÓRICO DE COMMITS

commit ca82a6dff817ec66f44342007202690a93763949 (HEAD -> master, origin/master, origin/HEAD)
Author: Scott Chacon <schacon@[Link]>
Date: Mon Mar 17 21:52:11 2008 -0700

changed the verison number

Rakefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <schacon@[Link]>
Date: Sat Mar 15 16:40:33 2008 -0700

removed unnecessary test code git log --stat

lib/[Link] | 5 -----
1 file changed, 5 deletions(-)

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <schacon@[Link]>
Date: Sat Mar 15 10:31:28 2008 -0700

first commit

README | 6 ++++++
Rakefile | 23 +++++++++++++++++++++++
lib/[Link] | 25 +++++++++++++++++++++++++
3 files changed, 54 insertions(+)

166

166

83
 VISUALIZANDO O HISTÓRICO DE COMMITS

• Exibe um gráfico ASCII que mostra a

estrutura de branches e merges no
histórico de commits. git log --graph
• É útil para visualizar a ramificação do
projeto

167

167

VISUALIZANDO O HISTÓRICO DE COMMITS

* commit ca82a6dff817ec66f44342007202690a93763949 (HEAD -> master, origin/master, origin/HEAD)

| Author: Scott Chacon <schacon@[Link]>
| Date: Mon Mar 17 21:52:11 2008 -0700
|
| changed the verison number
|
* commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
|
|
Author: Scott Chacon <schacon@[Link]>
Date: Sat Mar 15 16:40:33 2008 -0700
git log --graph
|
| removed unnecessary test code
|
* commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <schacon@[Link]>
Date: Sat Mar 15 10:31:28 2008 -0700

168

168

84
 VISUALIZANDO O HISTÓRICO DE COMMITS

Modifica o formato de saída do log

• oneline: Exibe cada commit em uma única

linha. git log --pretty=oneline
• short, full, fuller: Variam a
quantidade de informações exibidas.

169

169

VISUALIZANDO O HISTÓRICO DE COMMITS

ca82a6dff817ec66f44342007202690a93763949 (HEAD -> master, origin/master, origin/HEAD)

changed the verison number

085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code

a11bef06a3f659402fe7563abf99ad00de2209e6 first commit

git log --pretty=oneline

170

170

85
 PERSONALIZANDO A SAÍDA DO GIT LOG

git log --pretty=format:"%h - %an, %ar : %s"

ca82a6d - Scott Chacon, 6 years ago : Change version number
085bb3b - Scott Chacon, 6 years ago : Remove unnecessary test
a11bef0 - Scott Chacon, 6 years ago : Initial commit

• A opção mais interessante do --pretty é format

• Permite que você especifique seu próprio formato de saída de log.

• É útil quando você está gerando saída para processamento por máquina.

171

171

PERSONALIZANDO A SAÍDA DO GIT LOG

Especificador Descrição da Saída

%H Hash do commit

%h Hash do commit abreviado

%T Hash da árvore

%t Hash da árvore abreviado

%P Hashes dos commits-pai

%p Hashes dos commits-pai abreviados

%an Nome do autor

%ae E-mail do autor

%ad Data do commit pelo autor (respeita a opção --date=)

%ar Data do commit pelo autor, relativa

%cn Nome do comitador

%ce E-mail do comitador

%cd Data do commit pelo comitador

%cr Data do commit pelo comitador, relativa

%s Assunto (mensagem) do commit

172

172

86
 FILTRAGEM DE COMMITS NO GIT LOG
• Autor Específico

• git log --author="João":

• Intervalo de Tempo

• git log --since="2 weeks ago"

• git log --until="yesterday"

• Palavra-chave

• git log --grep="feat"

173

173

etiquetagem
No Git

174

174

87
 TAGS NO GIT
• O Git permite que você crie etiquetas
(tags);

• Que são marcadores que podem ser

aplicados a commits específicos.

• As Tags são frequentemente usadas

para marcar pontos de lançamento
(releases) e versões de software.

175

175

LISTAR TAGS NO GIT

git tag
Para ver todas as tags no git tag
v1.0
v2.0
repositório, use:

176

176

88
 LISTAR TAGS COM DETERMINADO PADRÃO

Para ver tags com um

git tag –l “v1.0.*”
determinado padrão, use:

177

177

EXEMPLO – LISTAGEM DE TAGS COM UM PADRÃO

• Um repositório, contém mais git tag -l "v1.8.5*"

v1.8.5
de 500 Tags; v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
• Você está interessado em v1.8.5-rc3
v1.8.5.1
v1.8.5.2
consultar apenas a série de v1.8.5.3
v1.8.5.4
versões 1.8.5 v1.8.5.5

178

178

89
 TAGS NO GIT

Existem dois tipos principais de tags no Git:

1. Tags Leves (Lightweight Tags)

2. Tags Anotadas (Annotated Tags)

179

179

1. TAGS LEVES (LIGHTWEIGHT TAGS)

• É essencialmente um ponteiro para

um commit específico;

• Não armazena informações adicionais, git tag v1.0.0

como:
• A data da tag

• O nome do criador

180

180

90
 CRIAR TAGS LEVES (LIGHTWEIGHT TAGS)

$ git tag v1.4-lw

• Para criar uma tag leve;
$ git tag
v0.1
• Basta fornecer o nome da tag; v1.3
v1.4
• Logo após o comando git tag v1.4-lw
v1.5

181

181

2. TAGS ANOTADAS (ANNOTATED TAGS)

• Ela armazena o nome do criador, a

data e uma mensagem;
git tag -a v1.0.0 -m "Primeira versão oficial"
• São recomendadas para marcar
versões de software, porque contêm
mais metadados.

182

182

91
 CRIAR TAGS ANOTADAS (ANNOTATED TAGS)

• Para criar uma tag anotada use as

flags –a e –m $ git tag -a v1.4 -m ”Versão 1.4”
$ git tag
• -a indica que é uma annotated tag; v0.1
v1.3
• -m permite que você adicione uma v1.4

mensagem associada à tag.

183

183

VISUALIZAR DETALHES DE UMA TAG

git show v1.4

tag v1.4
Tagger: Ben Straub <ben@[Link]>
Date: Sat May 3 20:19:12 2014 -0700
Para ver os detalhes de
Versão 1.4
uma tag anotada, use:
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@[Link]>
Date: Mon Mar 17 21:52:11 2008 -0700
Número de versão alterada

184

184

92
 CRIANDO TAGS RETROATIVAS

• Para criar uma tag em um

commit passado;
git tag -a v1.0.1 <hash-do-commit> -m "Patch de correção"

• Você pode especificar o hash

do commit.

185

185

EXEMPLO - CRIANDO TAGS RETROATIVAS

$ git tag -a v1.2 9fceb02

$ git show v1.2

• Suponha que você esqueceu
tag v1.2
de marcar o projeto na v1.2; Tagger: Scott Chacon <schacon@[Link]>
Date: Mon Feb 9 15:32:16 2009 -0800
• Que estava no commit
version 1.2
“Update rakefile”.
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <mchacon@[Link]>
Date: Sun Apr 27 20:43:35 2008 -0700
Update rakefile

186

186

93
 COMPARTILHANDO TAGS

• As tags não são enviadas automaticamente

para o repositório remoto;

• Com o comando git push git push origin --tags

• Para enviar todas as suas tags para o
repositório remoto, use:

187

187

COMPARTILHANDO TAGS

Para enviar um única tag, use: git push origin v1.0.0

188

188

94
 REMOVENDO TAGS

Para excluir uma tag localmente, use: git tag –d v1.0.0

189

189

REMOVENDO TAGS

Para excluir uma tag no

git push origin --delete v1.0.0
repositório remoto, use:

190

190

95
 Desfazendo operações
No Git

191

191

DESFAZENDO A PREPARAÇÃO DE UM ARQUIVO

Modificado Preparado (Staged)

Você pode acidentalmente preparar

arquivos que não queria incluir no
próximo commit.

Adicionar o
Arquivo

192

192

96
 DESFAZENDO A PREPARAÇÃO DE UM ARQUIVO

• Para remover um arquivo da área de

preparação;
git reset HEAD <arquivo>
• Mantendo as mudanças no diretório
de trabalho, use o comando:

193

193

EXEMPLO - DESFAZENDO A PREPARAÇÃO DE UM ARQUIVO

git add [Link]

git status

On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: [Link]
deleted: [Link]

Untracked files:
(use "git add <file>..." to include in what will be committed)
[Link]

O arquivo [Link] foi adicionado

acidentalmente na área de preparação

194

194

97
 EXEMPLO - DESFAZENDO A PREPARAÇÃO DE UM ARQUIVO

git reset HEAD [Link]

git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
deleted: [Link]

Untracked files:
(use "git add <file>..." to include in what will be committed)
[Link]
[Link]

O arquivo [Link] foi removido da área de preparação

com o comando git reset HEAD [Link]

195

195

DESFAZENDO A MODIFICAÇÃO DE UM ARQUIVO

Não Modificado Modificado

• Se você modificou um arquivo;

• E, decidiu que não quer manter

essas mudanças;

• Pode revertê-lo ao estado em

Editar o Arquivo
que estava no último commit.

196

196

98
 DESFAZENDO A MODIFICAÇÃO DE UM ARQUIVO

Para desfazer as mudanças

feitas nos arquivos use o git restore <arquivo>
comando:

197

197

EXEMPLO - DESFAZENDO A MODIFICAÇÃO DE UM ARQUIVO

• Esse comando descarta todas as

mudanças feitas no arquivo [Link]

• Ou seja, todas as linhas acrescentadas git restore [Link]

desde o último commit são apagadas

• Revertendo-o ao estado anterior.

198

198

99
 DESFAZENDO A PREPARAÇÃO DE UM ARQUIVO COM GIT RESTORE

• Remove o arquivo da área de

preparação com git restore
git restore --staged <arquivo>
• Faz a mesma coisa que git
reset HEAD <arquivo>

199

199

EXEMPLO - DESFAZENDO A PREPARAÇÃO DE UM ARQUIVO

git add [Link]

git status

On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: [Link]
deleted: [Link]

Untracked files:
(use "git add <file>..." to include in what will be committed)
[Link]

O arquivo [Link] foi adicionado

acidentalmente na área de preparação

200

200

100
 repositórios
Remotos

201

201

REPOSITÓRIOS REMOTOS

• Para colaborar em projetos Git, é essencial

saber como gerenciar repositórios remotos;

• Repositórios remotos são versões do seu

projeto que estão hospedadas em outro lugar;

• Seja na Internet ou em uma rede local.

202

202

101
 REPOSITÓRIOS REMOTOS

• A palavra “remoto” não implica

necessariamente que o repositório esteja na
rede ou na Internet;

• Apenas que esteja em outro lugar qualquer;

• Mesmo que estejam na mesma máquina,

eles ainda são considerados "remotos".

203

203

EXIBINDO SERVIDORES REMOTOS

• Para ver os servidores remotos configurados,

você pode usar o comando git remote.

• Ele lista os nomes curtos de cada remoto

git remote
que você configurou.

204

204

102
 EXIBINDO SERVIDORES REMOTOS

• Com a opção -v, você pode ver as URLs

associadas aos nomes curtos, que serão
usadas para leitura e escrita
$ git remote –v

• Esse comando listará todos os remotos

origin [Link] (fetch)
origin [Link] (push)
configurados, incluindo as URLs para:

• fetch (obter dados) - Leitura

• push (enviar dados) - Escrita

205

205

EXIBINDO SERVIDORES REMOTOS

• Se você tiver mais de um remoto, o $ git remote –v

comando lista todos eles;

bakkdoor [Link] (fetch)
bakkdoor [Link] (push)
• Isso significa que podemos extrair (pull)
cho45 [Link] (fetch)
contribuições de qualquer um desses cho45 [Link] (push)

usuários com bastante facilidade; defunkt [Link] (fetch)

defunkt [Link] (push)

• Podemos também ter permissão para koke git://[Link]/koke/[Link] (fetch)

koke git://[Link]/koke/[Link] (push)
enviar (push) contribuições para um ou
origin git@[Link]:mojombo/[Link] (fetch)
origin git@[Link]:mojombo/[Link] (push)
mais deles

206

206

103
 ADICIONANDO REPOSITÓRIOS REMOTOS

Você pode adicionar um novo

repositório remoto ao seu projeto Git git remote add <nome> <url>
com o comando git remote add

207

207

EXEMPLO - ADICIONANDO REPOSITÓRIOS REMOTOS

$ git remote add pb [Link]

• Neste exemplo estamos adicionando um repositório remoto de um

colaborador chamado Paulo;

• Agora, você pode usar pb no lugar da URL completa para comandos Git
como fetch e push.

208

208

104
 OBTENDO DADOS DOS SEUS REMOTOS

Para obter dados de um repositório

git fetch <remote>
remoto, use git fetch

209

209

EXEMPLO - FETCH

$ git fetch pb
• Se você quiser buscar todas as
informações que Paulo tem; remote: Counting objects: 43, done.
remote: Compressing objects: 100% (36/36), done.
• Mas que você ainda não tem em seu remote: Total 43 (delta 10), reused 31 (delta 5)
Unpacking objects: 100% (43/43), done.
repositório;
From [Link]
* [new branch] master -> pb/master
• Você pode executar git fetch pb
* [new branch] ticgit -> pb/ticgit

210

210

105
 OBTENDO DADOS DOS SEUS REMOTOS

• Esse comando busca todos os dados

que você ainda não tem no repositório
remoto especificado;

• Mas não os mesclará automaticamente git fetch <remote>

ao seu trabalho atual;

• Você pode mesclá-los manualmente

mais tarde.

211

211

OBTENDO DADOS DOS SEUS REMOTOS

• Se o branch atual está configurado para

rastrear um branch remoto, você pode usar
git pull

• Ele busca dados do servidor de onde você git pull

clonou originalmente

• E tenta mesclá-los automaticamente no código

no qual você está trabalhando no momento.

212

212

106
 ENVIANDO MUDANÇAS PARA SEUS REMOTOS

• Se você deseja compartilhar seu

trabalho;

• Você deve enviar suas mudanças git push <remote> <branch>

para o repositório remoto com
git push

213

213

EXEMPLO - ENVIANDO MUDANÇAS PARA SEUS REMOTOS

Para enviar sua ramificação principal

git push origin main
main para o remoto origin

214

214

107
 ENVIANDO MUDANÇAS PARA SEUS REMOTOS

Este comando funciona apenas se

• Você clonou de um servidor ao qual tem

acesso de escrita; git push origin main
• Ninguém mais tiver feito push nesse meio
tempo.

215

215

ENVIANDO MUDANÇAS PARA SEUS REMOTOS

• Se ao mesmo, outra pessoa clonar o repositório

tempo e fizer um push antes de você;

• Seu push será rejeitado.

• Você precisará buscar (fetch) o trabalho dessa git push origin main
pessoa

• E incorporá-lo ao seu antes de ser permitido

fazer o push.

216

216

108
 INSPECIONANDO UM REPOSITÓRIO REMOTO

Para ver mais informações sobre um

repositório remoto específico, use: git remote show <remote>

217

217

EXEMPLO - INSPECIONANDO UM REPOSITÓRIO REMOTO

$ git remote show origin

* remote origin
Fetch URL: [Link]
Push URL: [Link]

• Ele lista a URL para o repositório remoto; HEAD branch: master

• Bem como as informações do branch de Remote branches:

master tracked
rastreamento.
dev-branch tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)

218

218

109
 EXEMPLO - INSPECIONANDO UM REPOSITÓRIO REMOTO
$ git remote show origin

• Estes URLs são os endereços para os * remote origin

Fetch URL: [Link]
quais o Git se conecta para buscar
Push URL: [Link]
(fetch) e enviar (push) dados. HEAD branch: master

• Neste caso, ambos os URLs são Remote branches:

idênticos; master tracked

dev-branch tracked

• Apontando para o repositório ticgit do Local branch configured for 'git pull':
master merges with remote master
usuário schacon no GitHub. Local ref configured for 'git push':
master pushes to master (up to date)

219

219

EXEMPLO - INSPECIONANDO UM REPOSITÓRIO REMOTO

$ git remote show origin

* remote origin
• Isso indica que a branch padrão do repositório Fetch URL: [Link]

remoto é master; Push URL: [Link]

HEAD branch: master
• Quando você clonar este repositório; Remote branches:
master tracked
• O Git vai por padrão usar a branch master dev-branch tracked
Local branch configured for 'git pull':
como a branch principal.
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)

220

220

110
 EXEMPLO - INSPECIONANDO UM REPOSITÓRIO REMOTO
$ git remote show origin

* remote origin
• O Git está rastreando duas branches no Fetch URL: [Link]

repositório remoto: master e dev-branch. Push URL: [Link]

HEAD branch: master
• O termo "tracked" significa que o Git mantém Remote branches:
master tracked
uma cópia local dessas branches;
dev-branch tracked
Local branch configured for 'git pull':
• Para fins de comparação e sincronização.
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)

221

221

EXEMPLO - INSPECIONANDO UM REPOSITÓRIO REMOTO

$ git remote show origin
• A branch local master está configurada para
se mesclar automaticamente com a branch * remote origin
Fetch URL: [Link]
master do repositório remoto
Push URL: [Link]
HEAD branch: master
• Quando você executa o comando git
Remote branches:
pull. master tracked
dev-branch tracked
• Isso significa que, ao fazer um pull, o Git irá Local branch configured for 'git pull':

buscar as alterações da master remota e master merges with remote master

Local ref configured for 'git push':
tentar mesclá-las automaticamente na sua
master pushes to master (up to date)
branch master local.

222

222

111
 EXEMPLO - INSPECIONANDO UM REPOSITÓRIO REMOTO
$ git remote show origin

* remote origin
• A branch local master está configurada para Fetch URL: [Link]
Push URL: [Link]
enviar (push) suas alterações para a branch
HEAD branch: master
master do repositório remoto Remote branches:
master tracked
• Quando o comando git push for dev-branch tracked

executado. Local branch configured for 'git pull':

master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)

223

223

RENOMEANDO REMOTOS

Para renomear um repositório remoto, use:

git remote rename <nome-antigo> <novo-nome>

224

224

112
 RENOMEANDO REMOTOS

• Isso mudará o nome do remoto de pb

para Paulo;
git remote rename pb paulo
• Afetando também todos os nomes de
branches de rastreamento associados.

225

225

REMOVENDO REMOTOS

git remote remove <nome>

OU
Para remover um remoto use
git remote rm <nome>

226

226

113
 REMOVENDO REMOTOS

• O comando removerá o remoto paulo;

• Depois de excluir a referência a um controle

remoto dessa maneira;
git remote remove paulo
• Todas as ramificações de rastreamento
remoto e definições de configuração
associadas a esse controle remoto também
serão excluídas.

227

227

EM CASO DE INCÊNCIO

228

228

114
 BIBLIOGRAFIA

SOMMERVILLE, Ian. Engenharia de Software. Cap.

25 – Gerenciamento de Configuração. pág. 693.
Pearson, 2019.

229

BIBLIOGRAFIA

CHACON, Scott.; STRAUB, Ben. Pro GIT. Cap. 1, 2. Apress.

230

115
 BIBLIOGRAFIA

BOURQUE, Pierre.; FAIRLEY, Richard E. (Dick).

SWEBOK V3.0. Chapter 6. Software Configuration
Management, pág. 6-1. AMGH, 2021.

231

Diego Augusto Barros é bacharel em Sistemas de

Informação pela Pontifícia Universidade Católica de Minas
Gerais (2012) e mestre em Ciência da Computação pela
Universidade Federal de Minas Gerais (2015).

Sua pesquisa concentra-se nas áreas de Visualização de

PROF. DIEGO AUGUSTO BARROS
Dados e Interação Humano-computador, e investiga
fatores cognitivos e perceptivos envolvidos na análise de
grandes conjuntos de dados, que resultam em novos
sistemas interativos para comunicação e análise visual.
[Link]
Seus principais interesses nas áreas são: visualização de
@diegoaugustobarros informação, Visual Analytics, métodos de avaliação de
interfaces, interação com sistemas, tecnologias web,
@profdiegoaugusto
sistemas de informação, engenharia de software e
informática na educação.

232

116