gitUma breve

IntroduçãoAndrew Kurauchi (kurauchi@ime.usp.br)

GI ?+O que é o git?

ControledeVersões

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

Controle deVersões

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

Controle deVersões+ Linha de comandos

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

Controle deVersões+ Linha de comandos+ “Sistema de arquivos”

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

Controle deVersões+ Linha de comandos+ “Sistema de arquivos”+ Distribuído - Local

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

Como usargit?o

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

Comofuncionagit?o

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

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

Commitestado

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

Commitestado nome

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

Commitestado SHA1

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

Commitestado

pais

SHA1

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

Commitestado

pais autor

SHA1

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

Commitestado

pais autor

etc…SHA1

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

Workingdirectory

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

Workingdirectory

Index(staging

area)

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

Workingdirectory

Index(staging

area)

.git(repositório)

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

Workingdirectory

Index(staging

area)

.git(repositório)

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

Workingdirectory

Index(staging

area)

.git(repositório)

git init

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

Workingdirectory

Index(staging

area)

.git(repositório)

git checkoutgit init

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

Workingdirectory

Index(staging

area)

.git(repositório)

git checkoutgit init

git add

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

Workingdirectory

Index(staging

area)

.git(repositório)

git checkoutgit init

git add

git reset

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

Workingdirectory

Index(staging

area)

.git(repositório)

git checkoutgit init

git add

git reset

git co

mmit

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

Workingdirectory

Index(staging

area)

.git(repositório)

git checkoutgit init

git add

git reset

git co

mmit

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

Trabalhandocomcommits

reposino tório

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

DAGOs commits se organizam em forma de um DAG

DirectedAcyclicGraph

DAG: Grafo Acíclico Dirigido

A

Tempo

HEADmaster

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

A B

Tempo

HEADmaster

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

A B C

Tempo

HEADmaster

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

A B

Tempo

mastergit logC

HEAD

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

A C

Tempo

mastergit logB

HEAD

A B C

Tempo

mastergit log HEAD

A B C

Tempo

master HEAD

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

A B C

Tempo

mastergit branch HEAD

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

A B C

Tempo

mastergit branch HEAD

bug

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

A B C

Tempo

git commit

bug

HEADmaster

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

A B C

Tempo

git commit

bug

D

HEADmaster

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

A B C

Tempo

git commit

bug

D

HEADmaster

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

A B C

Tempo

git checkout

bug

D

HEADmaster

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

A B C

Tempo

git checkout

bug

D

HEAD

master

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

A B C

Tempo

git checkout

bug

D

HEAD

master

E

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

A B C

Tempo

git checkout

bug

D

HEAD

master

E

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

A B C

Tempo

git log

bug

D

HEAD

master

E

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

A B C

Tempo

git log

bug

D

HEAD

master

E

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

A B C

Tempo

bug

D

HEAD

E

F

H

G

master

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

A B C

Tempo

git merge

bug

D

HEAD

E

F

H

G

master

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

A B C

Tempo

git merge

bug

D

HEAD

E

F

H

G I

master

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

A B C

Tempo

git merge

bug

D

HEAD

E

F

H

G I

master

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

RepositórioRemoto

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

A B C

TempoHEADmaster Repositório

remoto

Repositório local

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

A B C

Tempo

git clone

HEADmaster Repositório remoto

Repositório local

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

A B C

Tempo

git clone

HEADmaster Repositório remoto

A B C

HEADmaster

Repositório local

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

A B C

Tempo

git clone

HEADmaster Repositório remoto

A B C

HEADmaster

Repositório local

origin/master

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

A B C

Tempo

git clone

HEADmaster Repositório remoto

A B C

HEADmaster

Repositório local

origin/master

(origin)

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

A B C

TempoHEADmaster Repositório

remoto

A B C

HEADmaster

Repositório local

origin/master

(origin)D

E

Suponha que seu colega fez um commit D na máquina dele e você fez um commit E na sua máquina. O seu repositório se encontra desatualizado. Para atualizá-lo basta executar o comando git fetch.

A B C

Tempo

git fetch

HEADmaster Repositório remoto

A B C

HEADmaster

Repositório local

origin/master

(origin)D

E

Suponha que seu colega fez um commit D na máquina dele e você fez um commit E na sua máquina. O seu repositório se encontra desatualizado. Para atualizá-lo basta executar o comando git fetch.

A B C

Tempo

git fetch

HEADmaster Repositório remoto

A B C

HEADmaster

Repositório local

origin/master

(origin)D

E

D

Suponha que seu colega fez um commit D na máquina dele e você fez um commit E na sua máquina. O seu repositório se encontra desatualizado. Para atualizá-lo basta executar o comando git fetch.

A B C

Tempo

git merge

HEADmaster Repositório remoto

A B C

HEADmaster

Repositório local

origin/master

(origin)D

E

D

Temos duas versões (branches) distintas. Devemos então unificá-las. Para isso novamente usamos o comando merge.

A B C

Tempo

git merge

HEADmaster Repositório remoto

A B C

HEADmaster

Repositório local

origin/master

(origin)D

E

DD

Temos duas versões (branches) distintas. Devemos então unificá-las. Para isso novamente usamos o comando merge.

A B C

Tempo

git pull

HEADmaster Repositório remoto

A B C

HEADmaster

Repositório local

origin/master

(origin)D

E

DD

Alternativamente podemos utilizar o git pull, que faz o fetch e o merge. Consulte http://marlacorinne.4parkers.com/2012/07/20/git-pull-vs-git-fetch-then-merge/ para uma discussão sobre pull X fetch+merge.

A B C

Tempo

git push

HEADmaster Repositório remoto

A B C

HEADmaster

Repositório local

origin/master

(origin)D

E

DD

Agora o origin está desatualizado. Devemos então atualizá-lo com o comando git push.

A B C

Tempo

git push

HEADmaster Repositório remoto

A B C

HEADmaster

Repositório local

origin/master

(origin)D

E

DD

E D

Agora o origin está desatualizado. Devemos então atualizá-lo com o comando git push.

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

CONCLUSÃOCONCLUSÃO

Para finalizar apresentaremos algumas dicas de onde ir e o que estudar a partir desse ponto.

Dicas

1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide);

2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;

3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível.

4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge.

5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

1. git rebaseDicas

1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide);

2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;

3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível.

4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge.

5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

1. git rebase2. mensagens de commit

Dicas

1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide);

2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;

3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível.

4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge.

5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

1. git rebase2. mensagens de commit3. commit antes de mudança

Dicas

1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide);

2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;

3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível.

4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge.

5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

1. git rebase2. mensagens de commit3. commit antes de mudança4. commit sempre

Dicas

1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide);

2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;

3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível.

4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge.

5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

1. git rebase2. mensagens de commit3. commit antes de mudança4. commit sempre5. master com versão funcional

Dicas

1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide);

2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo;

3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível.

4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge.

5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.

Revisando…

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

+ init: cria .gitRevisando…

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

+ init: cria .git+ add: adiciona no índice

Revisando…

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

+ init: cria .git+ add: adiciona no índice+ commit: cria commit

Revisando…

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

+ init: cria .git+ add: adiciona no índice+ commit: cria commit+ branch: cria branch

Revisando…

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

+ init: cria .git+ add: adiciona no índice+ commit: cria commit+ branch: cria branch+ merge: une branches

Revisando…

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

+ init: cria .git+ add: adiciona no índice+ commit: cria commit+ branch: cria branch+ merge: une branches+ pull/push: recebe/envia para o remoto

Revisando…

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

Links

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

+ Entendendo o git conceitualmente: http://www.sbf5.com/~cduan/technical/git/

Links

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

+ Entendendo o git conceitualmente: http://www.sbf5.com/~cduan/technical/git/

+ git (DAG): http://eagain.net/articles/git-for-computer-scientists/

Links

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

+ Entendendo o git conceitualmente: http://www.sbf5.com/~cduan/technical/git/

+ git (DAG): http://eagain.net/articles/git-for-computer-scientists/+ Tutorial interativo: https://try.github.io

Links

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

+ Entendendo o git conceitualmente: http://www.sbf5.com/~cduan/technical/git/

+ git (DAG): http://eagain.net/articles/git-for-computer-scientists/+ Tutorial interativo: https://try.github.io+ Tutorial "oficial": http://git-scm.com/docs/gittutorial

Links

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

+ Entendendo o git conceitualmente: http://www.sbf5.com/~cduan/technical/git/

+ git (DAG): http://eagain.net/articles/git-for-computer-scientists/+ Tutorial interativo: https://try.github.io+ Tutorial "oficial": http://git-scm.com/docs/gittutorial+ Fluxos de trabalho: https://www.atlassian.com/git/workflows

Links

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

+ Entendendo o git conceitualmente: http://www.sbf5.com/~cduan/technical/git/

+ git (DAG): http://eagain.net/articles/git-for-computer-scientists/+ Tutorial interativo: https://try.github.io+ Tutorial "oficial": http://git-scm.com/docs/gittutorial+ Fluxos de trabalho: https://www.atlassian.com/git/workflows+ Mostrando branch: http://www.vidageek.net/2009/07/20/

como-exibir-branch-atual-do-git/

Links

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