Introdução ao git

299 views

Published on

Uma breve introdução ao funcionamento do git.
Não são explicados os comandos com detalhes, mas sim como o git lida com a estrutura de commits.

Obs. Inclui notas nos slides para facilitar o entendimento.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
299
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Introdução ao git

  1. 1. gitUma breve Introdução Andrew Kurauchi (kurauchi@ime.usp.br)
  2. 2. GI ?+O que é o git?
  3. 3. Controle deVersões O git é um sistema de controle de versões. Ele pode ser utilizado para gerenciar as modificações em um código, texto, etc. ao longo do tempo.
  4. 4. ControledeVersões O git, assim como muitos outros sistemas de controle de versão foi feito inicialmente para ser utilizado por linha de comandos. Ele é implementado como um “mini sistema de arquivos” com muitas outras capacidades (histórico, etc). Além disso, diferentemente do SVN ou outros sistemas, é distribuído e local, ou seja, sempre temos uma cópia do repositório (local onde está guardado o histórico de mudanças) na nossa máquina. Veremos mais sobre isso adiante.
  5. 5. ControledeVersões + Linha de comandos O git, assim como muitos outros sistemas de controle de versão foi feito inicialmente para ser utilizado por linha de comandos. Ele é implementado como um “mini sistema de arquivos” com muitas outras capacidades (histórico, etc). Além disso, diferentemente do SVN ou outros sistemas, é distribuído e local, ou seja, sempre temos uma cópia do repositório (local onde está guardado o histórico de mudanças) na nossa máquina. Veremos mais sobre isso adiante.
  6. 6. ControledeVersões + Linha de comandos + “Sistema de arquivos” O git, assim como muitos outros sistemas de controle de versão foi feito inicialmente para ser utilizado por linha de comandos. Ele é implementado como um “mini sistema de arquivos” com muitas outras capacidades (histórico, etc). Além disso, diferentemente do SVN ou outros sistemas, é distribuído e local, ou seja, sempre temos uma cópia do repositório (local onde está guardado o histórico de mudanças) na nossa máquina. Veremos mais sobre isso adiante.
  7. 7. ControledeVersões + Linha de comandos + “Sistema de arquivos” + Distribuído - Local O git, assim como muitos outros sistemas de controle de versão foi feito inicialmente para ser utilizado por linha de comandos. Ele é implementado como um “mini sistema de arquivos” com muitas outras capacidades (histórico, etc). Além disso, diferentemente do SVN ou outros sistemas, é distribuído e local, ou seja, sempre temos uma cópia do repositório (local onde está guardado o histórico de mudanças) na nossa máquina. Veremos mais sobre isso adiante.
  8. 8. Comousar git?o Provavelmente você encontrará problemas em algum momento utilizando o git. Por esse motivo preferi não me ater tanto a como usá-lo com muitos detalhes (parâmetros, todos os comandos, etc).
  9. 9. Como funciona git?o Ao invés disso veremos como é o seu funcionamento básico. Após essa apresentação você deverá ser capaz de entender os comandos com mais detalhes. Essas explicações podem ser encontradas facilmente na internet.
  10. 10. Commit Para isso precisamos inicialmente entender o que é um commit. Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do commit e os armazena no repositório. Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s) para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.
  11. 11. Commit estado Para isso precisamos inicialmente entender o que é um commit. Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do commit e os armazena no repositório. Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s) para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.
  12. 12. Commit estado nome Para isso precisamos inicialmente entender o que é um commit. Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do commit e os armazena no repositório. Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s) para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.
  13. 13. Commit estado SHA1 Para isso precisamos inicialmente entender o que é um commit. Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do commit e os armazena no repositório. Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s) para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.
  14. 14. Commit estado pais SHA1 Para isso precisamos inicialmente entender o que é um commit. Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do commit e os armazena no repositório. Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s) para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.
  15. 15. Commit estado pais autor SHA1 Para isso precisamos inicialmente entender o que é um commit. Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do commit e os armazena no repositório. Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s) para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.
  16. 16. Commit estado pais autor etc… SHA1 Para isso precisamos inicialmente entender o que é um commit. Um commit é, de forma simplificada, uma “foto” da versão atual dos seus arquivos. O git comprime os arquivos do commit e os armazena no repositório. Ele é composto, entre outras coisas, por um nome (um hash SHA1) pelo qual podemos referenciá-lo, referência(s) para seu(s) pai(s) (commit(s) imediatamente anterior - veremos o porquê do plural), o autor do commit, etc.
  17. 17. Working directory Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados inicialmente ao índice (staging area). ! Alguns comandos: - git init: cria o repositório - git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory - git add: adiciona um arquivo novo/modificado no índice - git reset: retira um arquivo do índice (cuidado com esse comando) - git commit: cria o commit com as modificações encontradas no índice.
  18. 18. Working directory Index (staging area) Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados inicialmente ao índice (staging area). ! Alguns comandos: - git init: cria o repositório - git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory - git add: adiciona um arquivo novo/modificado no índice - git reset: retira um arquivo do índice (cuidado com esse comando) - git commit: cria o commit com as modificações encontradas no índice.
  19. 19. Working directory Index (staging area) .git (repositório) Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados inicialmente ao índice (staging area). ! Alguns comandos: - git init: cria o repositório - git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory - git add: adiciona um arquivo novo/modificado no índice - git reset: retira um arquivo do índice (cuidado com esse comando) - git commit: cria o commit com as modificações encontradas no índice.
  20. 20. Working directory Index (staging area) .git (repositório) Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados inicialmente ao índice (staging area). ! Alguns comandos: - git init: cria o repositório - git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory - git add: adiciona um arquivo novo/modificado no índice - git reset: retira um arquivo do índice (cuidado com esse comando) - git commit: cria o commit com as modificações encontradas no índice.
  21. 21. Working directory Index (staging area) .git (repositório) git init Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados inicialmente ao índice (staging area). ! Alguns comandos: - git init: cria o repositório - git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory - git add: adiciona um arquivo novo/modificado no índice - git reset: retira um arquivo do índice (cuidado com esse comando) - git commit: cria o commit com as modificações encontradas no índice.
  22. 22. Working directory Index (staging area) .git (repositório) git checkout git init Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados inicialmente ao índice (staging area). ! Alguns comandos: - git init: cria o repositório - git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory - git add: adiciona um arquivo novo/modificado no índice - git reset: retira um arquivo do índice (cuidado com esse comando) - git commit: cria o commit com as modificações encontradas no índice.
  23. 23. Working directory Index (staging area) .git (repositório) git checkout git init git add Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados inicialmente ao índice (staging area). ! Alguns comandos: - git init: cria o repositório - git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory - git add: adiciona um arquivo novo/modificado no índice - git reset: retira um arquivo do índice (cuidado com esse comando) - git commit: cria o commit com as modificações encontradas no índice.
  24. 24. Working directory Index (staging area) .git (repositório) git checkout git init git add git reset Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados inicialmente ao índice (staging area). ! Alguns comandos: - git init: cria o repositório - git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory - git add: adiciona um arquivo novo/modificado no índice - git reset: retira um arquivo do índice (cuidado com esse comando) - git commit: cria o commit com as modificações encontradas no índice.
  25. 25. Working directory Index (staging area) .git (repositório) git checkout git init git add git reset gitcommit Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados inicialmente ao índice (staging area). ! Alguns comandos: - git init: cria o repositório - git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory - git add: adiciona um arquivo novo/modificado no índice - git reset: retira um arquivo do índice (cuidado com esse comando) - git commit: cria o commit com as modificações encontradas no índice.
  26. 26. Working directory Index (staging area) .git (repositório) git checkout git init git add git reset gitcommit Um arquivo pode estar em 3 estados diferentes. O repositório é um diretório onde estão armazenados os commits e todos os arquivos que formam o histórico. Quando o arquivo não está no repositório ou foi modificado ele se encontra no working directory. Os arquivos que serão incluídos no próximo commit devem ser adicionados inicialmente ao índice (staging area). ! Alguns comandos: - git init: cria o repositório - git checkout: copia o(s) arquivo(s) de algum commit no repositório para o working directory - git add: adiciona um arquivo novo/modificado no índice - git reset: retira um arquivo do índice (cuidado com esse comando) - git commit: cria o commit com as modificações encontradas no índice.
  27. 27. Trabalhando comcommits reposi notório Veremos agora como os commits se organizam no repositório e como é possível manipulá-los.
  28. 28. DAG Os commits se organizam em forma de um DAG
  29. 29. Directed Acyclic Graph DAG: Grafo Acíclico Dirigido
  30. 30. A Tempo HEADmaster Nesse grafo os commits são representados por vértices e as arestas representam a relação pai-filho (nesse exemplo, A é pai de B e B é pai de C). Além disso temos um apontador para a cabeça (último commit) da árvore. Esse apontador é chamado por padrão de “master”. Temos também um “apelido” (alias) para a cabeça: HEAD. Para boa parte das operações que executaremos o que importa é para onde o HEAD está apontando.
  31. 31. A B Tempo HEADmaster Nesse grafo os commits são representados por vértices e as arestas representam a relação pai-filho (nesse exemplo, A é pai de B e B é pai de C). Além disso temos um apontador para a cabeça (último commit) da árvore. Esse apontador é chamado por padrão de “master”. Temos também um “apelido” (alias) para a cabeça: HEAD. Para boa parte das operações que executaremos o que importa é para onde o HEAD está apontando.
  32. 32. A B C Tempo HEADmaster Nesse grafo os commits são representados por vértices e as arestas representam a relação pai-filho (nesse exemplo, A é pai de B e B é pai de C). Além disso temos um apontador para a cabeça (último commit) da árvore. Esse apontador é chamado por padrão de “master”. Temos também um “apelido” (alias) para a cabeça: HEAD. Para boa parte das operações que executaremos o que importa é para onde o HEAD está apontando.
  33. 33. A B Tempo mastergit log C HEAD Existe um comando chamado log que imprime o histórico de commits a partir do HEAD. Nesse exemplo teríamos: C, B, A
  34. 34. A C Tempo mastergit log B HEAD
  35. 35. A B C Tempo mastergit log HEAD
  36. 36. A B C Tempo master HEAD Suponha agora que encontraram um bug no seu código enquanto você estava implementando uma funcionalidade. Em muitos casos não é uma boa ideia implementar a funcionalidade e corrigir o bug ao mesmo tempo. Se algo der errado pode ser difícil encontrar o que precisa ser desfeito. Se estivéssemos em duas pessoas, por exemplo, uma poderia implementar a funcionalidade e a outra em PARALELO corrigiria o bug. Assim cada um terá uma versão diferente dos arquivos. Para criar essa “ramificação" basta usar o comando branch. Ele simplesmente cria mais um apontador, no caso chamado “bug”.
  37. 37. A B C Tempo mastergit branch HEAD Suponha agora que encontraram um bug no seu código enquanto você estava implementando uma funcionalidade. Em muitos casos não é uma boa ideia implementar a funcionalidade e corrigir o bug ao mesmo tempo. Se algo der errado pode ser difícil encontrar o que precisa ser desfeito. Se estivéssemos em duas pessoas, por exemplo, uma poderia implementar a funcionalidade e a outra em PARALELO corrigiria o bug. Assim cada um terá uma versão diferente dos arquivos. Para criar essa “ramificação" basta usar o comando branch. Ele simplesmente cria mais um apontador, no caso chamado “bug”.
  38. 38. A B C Tempo mastergit branch HEAD bug Suponha agora que encontraram um bug no seu código enquanto você estava implementando uma funcionalidade. Em muitos casos não é uma boa ideia implementar a funcionalidade e corrigir o bug ao mesmo tempo. Se algo der errado pode ser difícil encontrar o que precisa ser desfeito. Se estivéssemos em duas pessoas, por exemplo, uma poderia implementar a funcionalidade e a outra em PARALELO corrigiria o bug. Assim cada um terá uma versão diferente dos arquivos. Para criar essa “ramificação" basta usar o comando branch. Ele simplesmente cria mais um apontador, no caso chamado “bug”.
  39. 39. A B C Tempo git commit bug HEADmaster Agora se fizermos um novo commit D, que apontador deveria ser atualizado? Lembre-se que a nossa referência é o HEAD. Assim, o master passa a apontar para D e bug se mantém em C.
  40. 40. A B C Tempo git commit bug D HEADmaster Agora se fizermos um novo commit D, que apontador deveria ser atualizado? Lembre-se que a nossa referência é o HEAD. Assim, o master passa a apontar para D e bug se mantém em C.
  41. 41. A B C Tempo git commit bug D HEADmaster Agora se fizermos um novo commit D, que apontador deveria ser atualizado? Lembre-se que a nossa referência é o HEAD. Assim, o master passa a apontar para D e bug se mantém em C.
  42. 42. A B C Tempo git checkout bug D HEADmaster Assim, se quisermos trabalhar na branch “bug”, devemos mudar o HEAD para “bug" com o comando checkout. Com isso os novos commits estarão na branch “bug" e não na “master".
  43. 43. A B C Tempo git checkout bug D HEAD master Assim, se quisermos trabalhar na branch “bug”, devemos mudar o HEAD para “bug" com o comando checkout. Com isso os novos commits estarão na branch “bug" e não na “master".
  44. 44. A B C Tempo git checkout bug D HEAD master E Assim, se quisermos trabalhar na branch “bug”, devemos mudar o HEAD para “bug" com o comando checkout. Com isso os novos commits estarão na branch “bug" e não na “master".
  45. 45. A B C Tempo git checkout bug D HEAD master E Assim, se quisermos trabalhar na branch “bug”, devemos mudar o HEAD para “bug" com o comando checkout. Com isso os novos commits estarão na branch “bug" e não na “master".
  46. 46. A B C Tempo git log bug D HEAD master E Agora se executarmos um git log devemos ver (lembre-se que a referência é o HEAD): E, C, B, A Se fizermos um checkout para master e reexecutarmos o log teremos: D, C, B, A
  47. 47. A B C Tempo git log bug D HEAD master E Agora se executarmos um git log devemos ver (lembre-se que a referência é o HEAD): E, C, B, A Se fizermos um checkout para master e reexecutarmos o log teremos: D, C, B, A
  48. 48. A B C Tempo bug D HEAD E F H G master Suponha que você terminou de corrigir o bug. Temos agora duas versões diferentes do nosso projeto. Precisamos unificar as mudanças. Para isso utilizamos o comando merge (note que estamos na branch master). Ele unifica as versões dos arquivos e cria um novo commit I. ! É possível que o mesmo arquivo possua modificações diferentes na mesma linha em ambas as branches. Nesse caso o git não saberá como resolver o conflito e o deixará indicado. Se isso acontecer (e vai acontecer) não se desespere. Basta manualmente abrir o arquivo, resolver o conflito e criar um novo commit.
  49. 49. A B C Tempo git merge bug D HEAD E F H G master Suponha que você terminou de corrigir o bug. Temos agora duas versões diferentes do nosso projeto. Precisamos unificar as mudanças. Para isso utilizamos o comando merge (note que estamos na branch master). Ele unifica as versões dos arquivos e cria um novo commit I. ! É possível que o mesmo arquivo possua modificações diferentes na mesma linha em ambas as branches. Nesse caso o git não saberá como resolver o conflito e o deixará indicado. Se isso acontecer (e vai acontecer) não se desespere. Basta manualmente abrir o arquivo, resolver o conflito e criar um novo commit.
  50. 50. A B C Tempo git merge bug D HEAD E F H G I master Suponha que você terminou de corrigir o bug. Temos agora duas versões diferentes do nosso projeto. Precisamos unificar as mudanças. Para isso utilizamos o comando merge (note que estamos na branch master). Ele unifica as versões dos arquivos e cria um novo commit I. ! É possível que o mesmo arquivo possua modificações diferentes na mesma linha em ambas as branches. Nesse caso o git não saberá como resolver o conflito e o deixará indicado. Se isso acontecer (e vai acontecer) não se desespere. Basta manualmente abrir o arquivo, resolver o conflito e criar um novo commit.
  51. 51. A B C Tempo git merge bug D HEAD E F H G I master Suponha que você terminou de corrigir o bug. Temos agora duas versões diferentes do nosso projeto. Precisamos unificar as mudanças. Para isso utilizamos o comando merge (note que estamos na branch master). Ele unifica as versões dos arquivos e cria um novo commit I. ! É possível que o mesmo arquivo possua modificações diferentes na mesma linha em ambas as branches. Nesse caso o git não saberá como resolver o conflito e o deixará indicado. Se isso acontecer (e vai acontecer) não se desespere. Basta manualmente abrir o arquivo, resolver o conflito e criar um novo commit.
  52. 52. Repositório Remoto Suponha agora que seu colega de trabalho possui um repositório na máquina dele e você gostaria de colaborar no mesmo projeto. Lembrando que o git sempre cria uma cópia local precisamos entender como funcionam os mecanismos de comunicação entre repositórios.
  53. 53. A B C Tempo HEADmaster Repositório remoto Repositório local Chamaremos de repositório na máquina de seu colega de repositório remoto. Convencionalmente se chama tal repositório de “origin”. Para criar uma cópia de origin em sua máquina utilizamos o comando “clone”, que cria uma cópia exata do repositório. Porém o apontador “master" no repositório local aponta para os commits na sua máquina, enquanto o “master" de origin aponta para os commits naquele repositório. Assim se ocorrer alguma atualização pode ser difícil encontrar as diferenças entre os repositórios. Para isso existe um apontador “origin/master” que é uma referência ao master da origin.
  54. 54. A B C Tempo git clone HEADmaster Repositório remoto Repositório local Chamaremos de repositório na máquina de seu colega de repositório remoto. Convencionalmente se chama tal repositório de “origin”. Para criar uma cópia de origin em sua máquina utilizamos o comando “clone”, que cria uma cópia exata do repositório. Porém o apontador “master" no repositório local aponta para os commits na sua máquina, enquanto o “master" de origin aponta para os commits naquele repositório. Assim se ocorrer alguma atualização pode ser difícil encontrar as diferenças entre os repositórios. Para isso existe um apontador “origin/master” que é uma referência ao master da origin.
  55. 55. A B C Tempo git clone HEADmaster Repositório remoto A B C HEADmaster Repositório local Chamaremos de repositório na máquina de seu colega de repositório remoto. Convencionalmente se chama tal repositório de “origin”. Para criar uma cópia de origin em sua máquina utilizamos o comando “clone”, que cria uma cópia exata do repositório. Porém o apontador “master" no repositório local aponta para os commits na sua máquina, enquanto o “master" de origin aponta para os commits naquele repositório. Assim se ocorrer alguma atualização pode ser difícil encontrar as diferenças entre os repositórios. Para isso existe um apontador “origin/master” que é uma referência ao master da origin.
  56. 56. A B C Tempo git clone HEADmaster Repositório remoto A B C HEADmaster Repositório local origin/master Chamaremos de repositório na máquina de seu colega de repositório remoto. Convencionalmente se chama tal repositório de “origin”. Para criar uma cópia de origin em sua máquina utilizamos o comando “clone”, que cria uma cópia exata do repositório. Porém o apontador “master" no repositório local aponta para os commits na sua máquina, enquanto o “master" de origin aponta para os commits naquele repositório. Assim se ocorrer alguma atualização pode ser difícil encontrar as diferenças entre os repositórios. Para isso existe um apontador “origin/master” que é uma referência ao master da origin.
  57. 57. A B C Tempo git clone HEADmaster Repositório remoto A B C HEADmaster Repositório local origin/master (origin) Chamaremos de repositório na máquina de seu colega de repositório remoto. Convencionalmente se chama tal repositório de “origin”. Para criar uma cópia de origin em sua máquina utilizamos o comando “clone”, que cria uma cópia exata do repositório. Porém o apontador “master" no repositório local aponta para os commits na sua máquina, enquanto o “master" de origin aponta para os commits naquele repositório. Assim se ocorrer alguma atualização pode ser difícil encontrar as diferenças entre os repositórios. Para isso existe um apontador “origin/master” que é uma referência ao master da origin.
  58. 58. A B C Tempo HEADmaster Repositório remoto A B C HEADmaster Repositório local origin/master (origin) D E Suponha que seu colega fez um commit D na máquina dele e você fez um commit E na sua máquina. O seu repositório se encontra desatualizado. Para atualizá-lo basta executar o comando git fetch.
  59. 59. A B C Tempo git fetch HEADmaster Repositório remoto A B C HEADmaster Repositório local origin/master (origin) D E Suponha que seu colega fez um commit D na máquina dele e você fez um commit E na sua máquina. O seu repositório se encontra desatualizado. Para atualizá-lo basta executar o comando git fetch.
  60. 60. A B C Tempo git fetch HEADmaster Repositório remoto A B C HEADmaster Repositório local origin/master (origin) D E D Suponha que seu colega fez um commit D na máquina dele e você fez um commit E na sua máquina. O seu repositório se encontra desatualizado. Para atualizá-lo basta executar o comando git fetch.
  61. 61. A B C Tempo git merge HEADmaster Repositório remoto A B C HEADmaster Repositório local origin/master (origin) D E D Temos duas versões (branches) distintas. Devemos então unificá-las. Para isso novamente usamos o comando merge.
  62. 62. A B C Tempo git merge HEADmaster Repositório remoto A B C HEADmaster Repositório local origin/master (origin) D E D D Temos duas versões (branches) distintas. Devemos então unificá-las. Para isso novamente usamos o comando merge.
  63. 63. A B C Tempo git pull HEADmaster Repositório remoto A B C HEADmaster Repositório local origin/master (origin) D E D D Alternativamente podemos utilizar o git pull, que faz o fetch e o merge. Consulte http://marlacorinne. 4parkers.com/2012/07/20/git-pull-vs-git-fetch-then-merge/ para uma discussão sobre pull X fetch+merge.
  64. 64. A B C Tempo git push HEADmaster Repositório remoto A B C HEADmaster Repositório local origin/master (origin) D E D D Agora o origin está desatualizado. Devemos então atualizá-lo com o comando git push.
  65. 65. A B C Tempo git push HEADmaster Repositório remoto A B C HEADmaster Repositório local origin/master (origin) D E D D E D Agora o origin está desatualizado. Devemos então atualizá-lo com o comando git push.
  66. 66. Note que não importa se a máquina do seu colega é a mesma que a sua, ou se está na mesma rede (é possível fazer clone via ssh, por exemplo). Assim, poderia existir um servidor central com os repositórios remotos a partir dos quais os participantes de um projeto poderiam fazer os clones locais. É essa a ideia do github (https://github.com/), bitbucket (https://bitbucket.org/) e outros. Em ambos basta fazer um cadastro e começar criar os repositórios. E ambos possuem versões gratuitas (no Github só é possível ter repositórios de código aberto em uma conta gratuita) com limitações de número de colaboradores e tamanho do projeto e pagas.
  67. 67. CONCLUSÃOCONCLUSÃO Para finalizar apresentaremos algumas dicas de onde ir e o que estudar a partir desse ponto.
  68. 68. Dicas 1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide); 2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo; 3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/ Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível. 4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge. 5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.
  69. 69. 1. git rebase Dicas 1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide); 2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo; 3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/ Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível. 4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge. 5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.
  70. 70. 1. git rebase 2. mensagens de commit Dicas 1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide); 2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo; 3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/ Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível. 4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge. 5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.
  71. 71. 1. git rebase 2. mensagens de commit 3. commit antes de mudança Dicas 1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide); 2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo; 3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/ Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível. 4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge. 5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.
  72. 72. 1. git rebase 2. mensagens de commit 3. commit antes de mudança 4. commit sempre Dicas 1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide); 2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo; 3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/ Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível. 4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge. 5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.
  73. 73. 1. git rebase 2. mensagens de commit 3. commit antes de mudança 4. commit sempre 5. master com versão funcional Dicas 1) Se quiser evitar commits de merge pesquise sobre git rebase (é possível encontrar mais detalhes nos links do último slide); 2) Sempre coloque mensagens em seus commits. O nome (hash SHA1) não diz nada sobre ele e sem mensagens expressivas você perde o controle de onde ocorreram as mudanças depois de pouco tempo; 3) Antes de fazer um pull, merge, checkout, etc. faça um commit ou faça um stash (http://git-scm.com/book/pt-br/ Ferramentas-do-Git-Fazendo-Stash). É possível executar alguns desses comandos com modificações nos arquivos, mas é (bastante) possível que ocorra algo imprevisível. 4) Faça muitos commits. Diferentemente do svn não é necessário utilizar a rede para realizar um commit, são só operações locais, assim é um processo muito rápido. Commits com pequenas mudanças ajudam no entendimento do histórico posteriormente e facilitam na hora de fazer um merge. 5) Um possível fluxo de trabalho é sempre manter a branch master com uma versão funcional do código.
  74. 74. Revisando… Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.
  75. 75. + init: cria .git Revisando… Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.
  76. 76. + init: cria .git + add: adiciona no índice Revisando… Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.
  77. 77. + init: cria .git + add: adiciona no índice + commit: cria commit Revisando… Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.
  78. 78. + init: cria .git + add: adiciona no índice + commit: cria commit + branch: cria branch Revisando… Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.
  79. 79. + init: cria .git + add: adiciona no índice + commit: cria commit + branch: cria branch + merge: une branches Revisando… Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.
  80. 80. + init: cria .git + add: adiciona no índice + commit: cria commit + branch: cria branch + merge: une branches + pull/push: recebe/envia para o remoto Revisando… Uma revisão simplificada de alguns dos comandos vistos ao longo da apresentação.
  81. 81. Links Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam outros conteúdos que não estão presentes nessa apresentação. Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os principais comandos a serem utilizados no dia a dia. Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes. O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git. O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.
  82. 82. + Entendendo o git conceitualmente: http://www.sbf5.com/ ~cduan/technical/git/ Links Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam outros conteúdos que não estão presentes nessa apresentação. Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os principais comandos a serem utilizados no dia a dia. Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes. O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git. O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.
  83. 83. + Entendendo o git conceitualmente: http://www.sbf5.com/ ~cduan/technical/git/ + git (DAG): http://eagain.net/articles/git-for-computer-scientists/ Links Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam outros conteúdos que não estão presentes nessa apresentação. Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os principais comandos a serem utilizados no dia a dia. Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes. O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git. O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.
  84. 84. + Entendendo o git conceitualmente: http://www.sbf5.com/ ~cduan/technical/git/ + git (DAG): http://eagain.net/articles/git-for-computer-scientists/ + Tutorial interativo: https://try.github.io Links Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam outros conteúdos que não estão presentes nessa apresentação. Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os principais comandos a serem utilizados no dia a dia. Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes. O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git. O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.
  85. 85. + Entendendo o git conceitualmente: http://www.sbf5.com/ ~cduan/technical/git/ + git (DAG): http://eagain.net/articles/git-for-computer-scientists/ + Tutorial interativo: https://try.github.io + Tutorial "oficial": http://git-scm.com/docs/gittutorial Links Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam outros conteúdos que não estão presentes nessa apresentação. Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os principais comandos a serem utilizados no dia a dia. Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes. O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git. O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.
  86. 86. + Entendendo o git conceitualmente: http://www.sbf5.com/ ~cduan/technical/git/ + git (DAG): http://eagain.net/articles/git-for-computer-scientists/ + Tutorial interativo: https://try.github.io + Tutorial "oficial": http://git-scm.com/docs/gittutorial + Fluxos de trabalho: https://www.atlassian.com/git/workflows Links Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam outros conteúdos que não estão presentes nessa apresentação. Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os principais comandos a serem utilizados no dia a dia. Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes. O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git. O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.
  87. 87. + Entendendo o git conceitualmente: http://www.sbf5.com/ ~cduan/technical/git/ + git (DAG): http://eagain.net/articles/git-for-computer-scientists/ + Tutorial interativo: https://try.github.io + Tutorial "oficial": http://git-scm.com/docs/gittutorial + Fluxos de trabalho: https://www.atlassian.com/git/workflows + Mostrando branch: http://www.vidageek.net/2009/07/20/ como-exibir-branch-atual-do-git/ Links Os dois primeiros links são a base para a explicação do repositório como um grafo acíclico dirigido e apresentam outros conteúdos que não estão presentes nessa apresentação. Outro link interessante é o tutorial interativo do github. É bem rápido e permite entender de forma bem prática os principais comandos a serem utilizados no dia a dia. Para quem tiver mais paciência é possível ler a documentação oficial no site do git com muitos outros detalhes. O link sobre fluxos de trabalho apresenta outras maneiras de trabalhar em grupo com o git. O último link é mais uma dica prática de como sempre mostrar no terminal a branch atual.

×